Fit gap что это
Использование GAP-анализа для выявления и согласования задач по проекту
Существует множество методов оценки эффективности работы компании в целом или на уровне определенных бизнес-процессов, которые включают в себя выявление «узких мест», описание непосредственно проблематики, выявление разницы между желаемым уровнем эффективности и реальной ситуацией. Я уже рассказывал о том, как на практике можно использовать использовать различные методы для выявления проблемных «узких мест», для планирования работы, для взаимодействия с заказчиком и демонстрации предложенных решений. Все это и многое другое вы можете прочитать в статьях Краткое описание BPMN с примером и Знакомство с нотацией IDEF0 и пример использования.
Сейчас я хочу рассказать еще об одной из распространенных сегодня методик – использовании GAP-анализа. В переводе с английского «gap» означает «разрыв», т.е. этот вид анализа можно назвать полностью по-русски анализом разрывов. Здесь в наглядной графической форме показаны графики желаемого развития событий и реального, видны проблемные «узкие места» в бизнес-процессах, что дает возможность руководителю сконцентрироваться на том участке, который действительно требует переосмысления и внедрения изменений, и, как следствие, принятию грамотных управленческих решений.
Для специалистов в сфере бизнес-консалтинга этот инструмент может стать эффективным помощником в следующих вопросах:
Основные этапы работы по проекту
Сотрудничество компании с приглашенными на условиях консалтинга специалистами чаще всего реализуется в одном из двух вариантов – постоянное сервисное обслуживание и некий проект, ограниченный выполнением определенной задачи в определенных сроки. И если при обслуживании просто оговариваются обязанности, которые на постоянной основе и по мере необходимости должны выполнять приглашенные специалисты, то этапы проекта стоит рассмотреть подробнее.
Основные этапы сотрудничества по проекту (Источник “Управленческое консультирование. Введение в профессию” под редакцией Милана Кубра):
Почему так важна диагностика?
Для начала, давайте разберемся, что ожидает от диагностики заказчик, и какой результат этого этапа важен для исполнителя-специалиста.
Основная цель диагностики – это получение готового перечня задач, согласованных с клиентом, на основе которых можно будет реализовывать последующие этапы работы.
Для заказчика помимо этого также важна стоимость выполнения работ, которую ни один настоящий специалист не сможет назвать до того, как перечень задач будет точно сформирован. Как известно, услуга без цены – это не услуга, а просто перечень идей. А потому согласованный перечень задач и сумма – одинаково важные составляющие результатов диагностики.
В различных случаях этап диагностики может занимать и менее 1 дня, и 2 недели и даже более. Все зависит от сложности поставленных задач и необходимых работ, относящихся к этому этапу. В отдельных случаях (при выполнении предпроектного обследования и т.д.) этап диагностики может быть очень трудоемким, а результат этого этапа будет отдельной оплачиваемой услугой.
Но в любом случае результаты должны быть следующие:
Виды диагностики
В зависимости от сложности необходимых работ, а также от того, что желает получить заказчик, диагностика может быть как очень простой и даже «символической», так и полноценным и сложным этапом.
Самые распространенные варианты я разделяю следующим образом:
Экспресс-диагностика
В этом случае заказчик высылает или озвучивает перечень задач, которые с точки зрения исполнителя являются типовыми. Т.е. исполнитель понимает, каким образом будут реализованы поставленные задачи, может быстро оценить сроки и озвучить цену выполнения работ. Максимум, что может потребоваться в процессе экспресс-диагностики, это проведение интервью с заказчиком или руководителем подразделения, с которым будет проводиться работа, для уточнения тех или иных особенностей работы компании.
Например, может понадобиться уточнить, с какой учетной системой работает компания, на какой CMS реализован сайт, кто является телефонным провайдером или уточнить еще какие-то моменты, способные повлиять на методы реализации и, как следствие, на общую стоимость работ. Этот вид диагностики можно применять в случаях, когда заказчику требуются какие-то виды типовых услуг, которые будут проводиться по шаблону. Длительность этого вида диагностики – до 1 рабочего дня (чаще 1-2 часа). Результат – калькуляция для клиента или выставленный счет к оплате.
Разработка технического задания (ТЗ)
В некоторых случаях клиент высылает готовое ТЗ, тогда диагностика и даже планирование сводятся к минимуму. Но часто специалистам приходится составлять техзадание самостоятельно, на основе интервью с заказчиком и анализа проблем. В этом документе описываются все требования, желаемый результат, полный перечень задач по проекту, необходимых технических решений и т.д. Техническое задание также является основанием для оценки сроков и подсчета стоимости выполнения работ.
ТЗ от заказчика: плюсы и минусы:
В результате очень часто заказчик чаще всего в свободной форме перечисляет все свои пожелания, исполнитель составляет техническое задание самостоятельно, после чего этот документ согласоваться с заказчиком (возможно с привлечением экспертов).
Предпроектное обследование
Такое обследование является само по себе отдельным видом работы, сравнительно сложным и трудоемким. В процессе обследования специалист:
В отличие от техзадания, результатом предпроектного обследования становится отчет, в котором отражаются описание окружения, проблематики, существующей ситуации. Также в отчете описывается, что нужно сделать для решения поставленных задач, какие могут быть стратегические предложения и т.д.
Это уже не просто задание, а некий всеобъемлющий документ, который описывает что имеется в реальности, что нужно сделать, что будет на выходе, и сколько это все будет стоить. Такой документ может занимать от 2-3 страниц до 15 и более. Причем, часто предпроектный отчет при всей своей информационной насыщенности оказывается менее объемным, чем техническое задание.
Причина такого явления – отсутствие в отчете предпроектного обследования необходимых в ТЗ технических данных, часто собранных в таблицы: соответствие и описание определенных параметров, например, соответствие полей в CRM и 1С при постановке задачи интеграции, другие таблицы с техническими параметрами. Одно такое описание вместе с комментариями к нему может занимать 3-5 страниц.
В отчете таких подробных описаний технических деталей нет. Они и не нужны клиенту для принятия решения. Зато здесь присутствует все, что необходимо заказчику: выявленная проблематика, подробное описание решения, информация для оценки возможных рисков. Такой документ содержит много полезной информации и решений, но он сам по себе обычно стоит сравнительно дорого.
GAP-анализ
При проведении GAP-анализа составляется некая нотация бизнес-процессов, где отражается одновременно существующая ситуация в реальности и результатом, который хотел бы получить заказчик. Чаще всего результаты GAP-анализа отображаются в графическом виде. Текстовое описание разрывов также возможно, но в этом случае результаты анализа теряют свою наглядность.
Нотации GAP-анализа позволяют в сжатые сроки оценить наиболее проблемные места, так называемые «разрывы», сконцентрировать на них максимум внимания при выборе решения и подробной разработкой этапов его реализации. В некоторых случаях к GAP-анализу для заказчиков также прилагается вариант решения.
Здесь очень важно понимать грань. Часто специалисты, которые сами выявляют «тонкие места» в бизнесе, предлагают решения для реализации бизнес-процессов так, как они видят, что и как должно быть. При работе с GAP-анализом я всегда показываю разрыв между ситуацией реальной и тем, как должно быть с точки зрения заказчика, в его формулировках, в его видении. Т.е. концентрируюсь на решении поставленных задач. И здесь графические нотации нужны именно для понимания заказчиком всех нюансов.
Свое видение того, как должно быть, я могу предлагать заказчикам в рамках предпроектного обследования, так как в таком случае часто заказывают услуги бизнес-консультанта именно для выявления проблем и поиска решений с точки зрения специалиста. Но если поставлена четкая задача, то и работать надо в рамках того, как именно заказчик видит желаемый результат.
Также я обычно предлагаю определенные решения, которые помогут исправить «разрывы», т.е. перейти от того, что есть сейчас, к тем результатам, которые являются желаемыми для заказчика.
Чаще всего подобный вариант анализа проводится в случае работы с определенным сегментом бизнеса, например, описывается отдельно бизнес-процесс отгрузки товара, обработки заявки с сайта и т.д.
Графические решения оформляются в удобном формате, я лично предпочитаю формат BPMN. В любом случае в результате заказчики видят наглядно существующие проблемные места в бизнес-процессе, а также идеи и решения. Заказчик видит в простой и наглядной форме, что вы точно поняли поставленную задачу и предлагаете ее решение.
Преимущества GAP-анализа
О том, что графические нотации – это один из очень удобных и эффективных вариантов работы с заказчиками при обсуждении любых изменений в бизнесе (внедрение IT-программ, оборудования для автоматизации, внедрение изменений в управленческий процесс и т.д.). Графические нотации позволяют избавиться от тысячи слов, а взаимопонимание с заказчиком будет намного выше, чем при отправке многостраничного текстового отчета. При этом экономится время – и ваше, и вашего клиента.
При этом GAP-анализ или, иначе говоря, анализ разрывов – это возможность показать на одной графической диаграмме одновременно и реальную ситуацию, и желаемую, а также увидеть наглядно, на каких именно этапах происходит снижение качества работы. Применение такого вида нотаций удобно и в процессе анализа и поиска эффективных решений поставленной задачи, и на этапе обоснования ваших решений заказчику.
При этом как инструмент в работе GAP-анализ достаточно прост, чтобы им сумел пользоваться не только профессиональный маркетолог, но также и разработчик ПО, занимающийся консалтингом, или любой другой специалист, который предлагает для бизнеса те или иные решения.
Также в настоящее время я готовлю к публикации книгу и онлайн курс, в которой подробно опишу собственное видение процессного подхода к бизнесу, а также мой собственный практический опыт работы в сфере функционального и процессного моделирования. Все желающие могут подписаться на уведомление о выходе новой книги по и другие новости ссылке.
Fit gap что это
Внедрение практически любой корпоративной информационной системы требует ее доработки для реализации как законодательных, так и специфических требований предприятия. Согласно [1], стандартный функционал КИС покрывает не более 30% бизнес-требований, все оставшиеся – реализуются разработками и донастройками системы. Ведение доработок ERP и ERP2-систем (ERP, Enterprise Resource Planning) – задача нетривиальная по причине того, что разрабатываемая программа должна успешно решать сформулированную бизнес-задачу, быть масштабируемой и расширяемой, а также не нарушать работу смежных модулей системы.
Определение 1. Корпоративная информационная система (КИС) – это расширяемая информационная система, предназначенная для комплексной автоматизации всех видов хозяйственной деятельности компаний, а также корпораций, требующих единого управления [2].
К сожалению, число литературных источников, посвященных проектированию и разработке подобных программ, не так велико, более того существует следующая крайность: либо повествование ведется исключительно для аудитории разработчиков, преимущественно описывая алгоритмы обработки данных, их оптимизацию и построение соответствующей структуры программы 3, либо теоретических проектировщиков – вводя всевозможные классы и типы систем и подпрограмм, банальные принципы и требования, не очевидные к реализации, что не дает ответа на вопрос, как правильно моделировать программу и отражать ее в задании на разработку. Конечно существуют различные ГОСТ’ы в области информационных систем [6, 7], однако подобные документы преимущественно описывают постановку задачи и требования к результатам нежели содержательную часть решения. Именно поэтому процесс проектирования программ весьма критичен и напрямую влияет на качество имплементации ERP/ERP2-систем.
Цель работы состоит в рассмотрении типовой структуры и содержания спецификации на доработку информационных систем, особенностей проектирования приложений и их отражения в документе спецификации, а также формировании универсальных требований к разрабатываемым программам. Для наглядности приводятся практические примеры из ERP-системы от компании SAP AG. Статья дополняет и расширяет содержание работ [8, 9], призвана восполнить пробелы ERP-аналитиков и консультантов при подготовке функциональной спецификации на разработку пользовательских программ. Реализация вышеуказанной цели потребует проработки следующих вопросов:
1. Fit/Gap-анализ и оценивание разработок
1.1. Проведение Fit/Gap-анализа
Кроме того, запускается фоновая задача по планированию материалов и отслеживаются результаты её работы. В случае выявления некорректно созданных документов после запуска ROP, идентифицируется причина и устраняются последствия. Чаще всего причинами ошибочно созданных документов являются несовершенство введения данных или ошибки пользователей при реализации процессов в КИС. Выполнив несколько раз упомянутые активности, ответственные пользователи получают опыт, позволяющий обрабатывать большие объёмы данных при последующем увеличении числа планируемых по ROP материалов.
Анализ, проектирование, конфигурирование и доработка, а также тестирование и внедрение ERP-системы на предприятии потребуют от полу года до полутора лет. Именно поэтому ведется группирование ключевых событий, работ и задач на этапы, уровни и команды, о чем подробно рассказывается в статье [10]. Выделение уровней имплементации КИС соответствует классическому подходу к описанию бизнес-архитектуры предприятия, дополненному активностями по управлению изменениями и непосредственно проектом (рис.1).
На уровне изменений решаются задачи оценивания численности человеческого персонала, его обучения работе с ERP-системой, а также перехода к продуктивному использованию КИС как с технической, так и бизнес точек зрения. Уровень проекта обеспечивает планирование, контроль выполнения и корректировку отклонений в ходе реализации задач всех уровней [11]: процессы, данные, приложения, техника и изменения.
Потребность в доработке информационной системы изначально определяется на этапе анализа, в последующем описывается на фазе проектирования и реализуется в процессе разработки. Очевидно, что разработка затрагивает самые содержательные уровни проекта внедрения ERP: процессы, данные, приложения и технику. В ходе выполнения процедуры Fit/Gap-анализа идентифицируются, описываются и приоритизируются бизнес-требования пользователей [12], которые согласно каскадной методологии внедрения КИС [13] ведутся в документе Матрицы отслеживания требований.
Рис. 1. Группирование работ и задач для: а) описания бизнес-архитектуры предприятия;
б) проекта внедрения ERP-системы
Определение 2. Матрица отслеживания требований (Requirement Traceability Matrix, RTM) – это таблица, позволяющая отслеживать ход обработки бизнес, пользовательских и функционально-технических требований от момента их идентификации до реализации посредствам конфигурирования и/или доработки корпоративной информационной системы.
Для каждого бизнес-требования относящегося к категории Gap в документе RTM указывается тип, сложность и процент ре-использования разработки, кроме того наименование подготавливаемой функциональной спецификации.
Определение 3. Функциональная спецификация на разработку (Functional Specification) – документ, описывающий технические детали разрабатываемой программы, позволяющей реализовать требования к информационной системе. Детали решения включает концептуальную схему программы, алгоритмы обработки данных и заполнения полей, структуру и взаимосвязь реализуемых таблиц баз данных.
Тип разработки определяется на основе RICEF-классификации всех пользовательских программ. Позже мы поговорим о данной классификации более подробно.
Определение 4. RICEF (сокращение от Report, Interface, Conversion, Enhancement и Form) – это классификация всех программных разработок на отчет, интерфейс, программу обработки данных, расширение и печатную форму [14].
Сложность программы чаще всего задается следующей шкалой:
Определение 5. Трудозатраты – это количество дней, затрачиваемое на выполнение работы силами одного человеческого ресурса, выражается в единице измерения человеко-дни. Срок выполнения работы имеет следующую зависимость от трудозатрат: Срок выполнения работы = Трудозатраты / Количество человеческих ресурсов.
значение которых может быть понижено при указании не нулевого %-переиспользования. Оценка ведется единожды и завершается не позже окончания фазы анализа. Назовем документ содержащий расчет трудозатрат для всех комбинаций типов и сложностей программ Оценщиком трудозатрат разработки. Пример фрагмента Оценщика и RTM даны на рис.2.
Определение 6. Оценщик трудозатрат разработки (RICEF Estimator) – это матрица, определяющая плановые трудозатраты на подготовку функциональной спецификации, разработку программы и ее функционально-модульное тестирование для каждого вида разработки RICEF и сложности.
Рис. 2. Пример фрагмента: а) RICEF Estimator;
б) RTM с указанием трудозатрат разработки на основе Оценщика
1.2. Оценивание RICEF-разработок
Использование Оценщика обеспечивает единый подход к определению плановых трудозатрат, необходимых для формирования спецификации на разработку. В случае, если разработка представляет собой совокупность нескольких программ, оценивание на основе RICEF Estimator проводится независимо для каждой из ее частей, а итоговые трудозатраты суммируются. Применение плановых значений трудозатрат соответствует PDCA-циклу (цикл Деминга), являющегося основой проектного менеджмент и постулирующего следующее: выполнению любой задачи предшествует шаг планирования, после чего ведется выполнение запланированных работ, далее контроль хода исполнения, а также корректировка возникших план-факт отклонений [11].
Индикативная оценка трудозатрат, необходимых для подготовки спецификации на разработку всевозможных видов программ дана на рис.3. Следуя данным рисунка, становится очевидным: формирование даже самой простой спецификации потребует значительных усилий в 4-7 человеко-дней. Указанная оценка должна быть принята во внимание еще на этапе планирования сроков. Игнорирование плановых трудозатрат, в частности их занижение, приведет к ожидаемым негативным последствиям: качество спецификации оставит желать лучшего, а сэкономленное время планомерно распределится на стадию разработки для устранения дефектов функционально-модульного тестирования.
Рис. 3. Индикативная оценка трудозатрат подготовки спецификации
(как часть документа RICEF Estimator)
Предварительно оценив время, необходимое для подготовки спецификации на разработку, обратимся к теории, для чего охарактеризуем виды разработок, а также введем базовые принципы, которым должна удовлетворять пользовательская программа на примере использования продукта SAP ERP.
2. RICEF-классификация разработок и принципы проектирования программ
2.1. Классификация разработок RICEF
Корпоративная информационная система состоит из большое числа программных разработок. RICEF-классификация позволяет отнести каждую из программ к определенному типу разработки, что накладывает ограничения как на структуру спецификации, так и время ее подготовки. Классификация RICEF расшифровывается следующим образом [14]:
Примеры программ согласно RICEF-классификации даны на рисунке ниже. На практике возможна ситуация, когда программная разработка состоит из множества взаимосвязанных подпрограмм. В этом случае классификации подлежит каждая подпрограмма, являющаяся частью сложного приложения.
Рис. 4. Примеры программ в SAP ERP по классификации RICEF с указанием кодов транзакций:
а) отчет; б) интерфейс; в) программа обработки данных; г) расширение; д) печатная форма
2.2. Принципы проектирования программ
Проектируемая RICEF-программа, в последующем отражаемая в спецификации на разработку, должна удовлетворять ряду правил. Например, быть масштабируемой в случае увеличения числа пользователей, гибкой к будущим изменениям, решать задачу оптимальным образом и прочее. Рассмотрим принципы разработки программ, заданные, но не ограниченные следующими предметными областями:
2.2.1. Принципы теории управления
Среди принципов теории управления: программный, по обратной связи, по возмущению и комбинированный, ведению программных разработок наиболее релевантно правило обратной связи [15]. Применительно к ERP-системам данный принцип заключается в следующем: разрабатываемая программа должна обеспечивать максимальное информирование пользователя о ходе работы, что немаловажно в случае возникновения непредвиденных обстоятельств и ошибок. Рис.5 демонстрирует пример реализации данного принципа в SAP ERP: при попытке сохранить документ Поступления к Заказу на Закупку было выявлено, что не заполнены обязательные поля, о чем система сообщает пользователю в информативном сообщении об ошибке.
Рис. 5. Пример возникновения ошибки в SAP ERP при попытке сохранить Приход,
не заполнив обязательные поля данных (транзакция MIGO)
2.2.2. Принципы системного анализа
В процесс разработки ERP-программ системный анализ привносит следующие принципы [16]:
Принцип функциональности подразумевает, что структура разрабатываемой программы КИС должна целиком и полностью определяться изначально поставленной задачей. Поэтому чрезмерно сложная, состоящая из большого числа кнопок, пунктов меню и подэкранов программа – неудачная попытка решения различных задач средствами одной программной разработки. Конечно, только в том случае, если программа не представляет собой автоматизированное рабочее место сотрудника, объединяющее множество подпрограмм, каждую из которых можно запустить независимо (рис.6).
Рис. 6. Пример печати формуляра в SAP ERP через: а) независимую программу печати (транзакция MB90); б) программу регистрации прихода продукции с возможностью запуска печати через дополнительный пункт меню (транзакция MIGO)
С течением времени каждая программа претерпевает изменения, т.е. развивается. Например, из-за введения новых законодательных требований, увеличения числа пользователей системы и прочее. Принцип развития диктует необходимость проектирования ERP-программ с учетом данного обстоятельства. Именно поэтому в SAP ERP заданная программа успешно функционирует со всевозможными объектами и типами данных, а также на различных организационных уровнях (рис.7). Следуя данному принципу, разработка отчета, который будет корректно работать, к примеру, только для одного завода, но не всех имеющихся, будет ошибочной.
Рис. 7. Пример отчета в SAP ERP, в котором можно указывать различные организационные уровни для просмотра складских запасов (транзакция MB52)
Рис. 8. Пример ошибки в SAP ERP при неправильном заполнении значения даты
(транзакция MB51)
Неопределенность в работе программы должна быть сведена к минимуму. Однако никто не застрахован от неправильных данных, подаваемых на вход программы пользователем системы. Сложность заключается в том, что анализ того, почему программа выдала тот или иной ошибочный результат на основе неправильно заполненных входных данных, займет гораздо больше времени нежели исключение возможности возникновения подобной ситуации. Поэтому «защита от дурака» требует организации всевозможных проверок для вводимых данных, что является содержанием принципа неопределенности (рис.8).
2.2.3. Принципы программирования
Обратимся к базовым правилам ведения программных разработок, среди которых можно выделить принципы 3:
Ситуация, когда один и тот же программный код многократно повторяется в тексте приложения согласно принципу модульности обрабатываться следующим образом: повторяющийся участок описывается единожды в виде процедуры, далее, если по ходу работы требуется выполнить этот участок кода, осуществляется запуск процедуры по ссылке. Принцип применим и для подготовки спецификации на разработку, что, к сожалению, ухудшает читабельность документа, так как приходится постоянно «перепрыгивать» между страницами, однако значительно сокращает трудозатраты в случае частого изменения документа (рис.9).
Рис. 9. Пример использования функционального модуля ‘FI_CHART_OF_ACCOUNT_DETERMINE’ различными программами SAP ERP (транзакция SE37)
Часто используемые программы должны находиться в оперативной памяти компьютера для возможности их быстрого запуска, что задает принцип функциональной избирательности. Примерами применения данного принципа в работе ERP-систем служат фоновые программы, выполняемые на регулярной основе вне поля зрения конечных пользователей, чаще всего в ночное время (рис.10).
Рис. 10. Пример монитора запланированных фоновых задач в SAP ERP (транзакция SM37)
Суть принципа «по умолчанию» однозначно определяется из его названия: все, что может уменьшить число ручных операций выполняемых пользователем, в частности, автоматическое заполнение данных в поля ввода программы, значительно облегчают ему жизнь. С точки зрения отражения требования в документе спецификации и сложности его разработки, казалось бы, мелочь, однако для конечных потребителей ERP-системы – это существенное сокращение трудозатрат (рис.11).
Рис. 11. Пример реализации принципа «по умолчанию» в SAP ERP за счет ручного указания пользовательских параметров (а) и их автозаполнение в поля отчета по складским запасам (б), используя транзакции SU01 и MMBE соответственно
Часто мы описываем и в дальнейшем реализуем программные разработки по созданию документов в ERP-системе, предполагая, что приложение будет запускаться довольно редко и на небольшом объеме данных. Исходя из этого, логика функционирования программы нередко оставляет желать лучшего. Допустим, как быть в случае, если программа отработала некорректно и созданные данные требуется аннулировать? Правило надежности говорит о том, что любая программа, создающая или изменяющая данные в КИС, должна обеспечивать возможность их последующего нахождения для целей корректировки или удаления. Именно поэтому в системе SAP ERP большая часть программ разработана и разделена на операции: создание, изменение, удаление и отображение в виде списка (рис.12).
Рис. 12. Пример пользовательского меню SAP ERP, содержащего программы по созданию, изменению и просмотру Заказов на Закупку (транзакции ME21N, ME22N и ME23N)
3. Моделирование приложения и подготовка к написанию спецификации
Нередко применение принципов разработки приложений привносит все новые и новые требования к реализации. В первую очередь давайте разберемся с тем, что же такое требование.
Определение 7. Требование – это настойчивая просьба выполнить что-либо, в контексте внедрения ERP-систем категоризируется на бизнес, пользовательские и функционально-технические. Первые две категории требований часто определяются законодательными изменениями и наиболее трудозатратными бизнес-операциями.
Имплементация ERP-систем, ориентированных на средний и малый бизнес, преимущественно ведется на основе водопадной методологии внедрения информационных систем [13]. Как дополнение к данной методологии часто применяется V-модель разработки через тестирование (рис.13). Особенностью модели является то, что она определяет и устанавливает четкое соответствие между видами требований и испытаний. Так вводятся бизнес, пользовательские и функциональные требования.
Рис. 13. V-модель разработки через тестирование
Первые два вида требований задаются бизнес-пользователями и носят общий и достаточно верхнеуровневый характер. Детали таких требований преимущественно отсутствуют либо могут по-разному трактоваться. Именно поэтому они подлежат детальной проработки и уточнению для получения четко сформулированных потребностей, реализацию которых легок проверить по результатам завершения разработки. Третий вид требований – функциональные, относящиеся к программной реализации и необходимые консультанту для проработки технических деталей, без которых решение будет неработоспособно.
Существует ряд способов идентификации требований, описание которых дано в [12]. Особо хочется отметить методы демонстрации системы заказчику и прототипирования, наиболее часто используемые на практике. Суть демонстрации (или Workshop, рабочая встреча) состоит в следующем: заказчику показывается существующая программная система в демо-режиме или на презентационных слайдах, после чего ведется уточнение и детализация требований. Прототипирование применяется, когда бизнес потребности не могут быть явно сформулированы, в этому случае создается предварительный рабочий макет программы, на основе которого совместными усилиями пользователей и специалистов определяются требования.
3.1. Проектирование структуры и логики работы программы
Идентифицированные пользовательские требования, относящиеся к категории Gap, а также соответствующие им функциональные потребности, отражаются в спецификации на разработку. В будущем данные требования будут покрыты программной разработкой в ERP-системе. Для этого, руководствуясь PDCA-принципом и предварительно оценив трудозатраты, ведется проектирование предварительной концепции решения как в текстовом, так и графическом видах.
Текстовое описание предполагает отражение наиболее критичных моментов работы программы, в то время как графическое – задание ее логической структуры.
В отличие от привычных всем офисных программ (например, MS Word и Excel, Lotus Notes и др.), ERP-системы оперируют большими данными. Поэтому отображение информации осуществляется преимущественно на экранные формы схожие с электронными таблицами, что удобно для целей последующего анализа. Ранее в статье [8] была введена трехуровневая структура описания программ, суть которой сводится к выделению в программной разработке экранов: селекционного, выбранных и обработанных данных. Используя данную структуру, осуществляется графическое моделирование программы, для чего визуализируются ее экраны и задаются логические взаимосвязи между ними (рис.14).
Определение 8. Трехуровневая структура описания программы – это способ моделирования структуры RICEF-программы, состоящий из описания селекционного экрана, экранов выбранных и обработанных данных, а также логики перехода между ними.
Рис. 14. Пример моделирования программы на основе трехуровневой структуры описания
Проектный опыт подтверждает, структура программы не ограничивается лишь тремя экранами, в частности, когда речь заходит о сложных разработках, содержащих большое число подэкранов, уровней и кнопок. Обобщим трехуровневую структуру описания программ, введя дополнительные пользовательские экраны.
Определение 9. Обобщенная структура описания программы – это расширение трехуровневой структуры описания программы, позволяющее выполнять моделирование не только селекционного экрана и экранов выбранных/обработанных данных, но и множества прочих подэкранов, запускаемых различными функциями разрабатываемого приложения.
Рис. 15. Применимость обобщенной структуры для описания сложных I и С-программ
Рис.15 демонстрирует применимость обобщенной структуры для моделирования программных разработок, состоящих из большого числа пользовательских экранов. Проектирование целесообразно вести, когда количество экранов больше или равно трем, в противном случае непросто понять логику работы приложения. Пример моделирования сложной программы, состоящей из шести экранов дан на рисунке ниже.
Рис. 16. Моделирование сложной программы на основе обобщенной структуры: а) селекционный экран; б) экран выбранных данных; в) экран обработанных данных; г-е) вспомогательные функциональные подэкраны
3.2. Моделирование экранов, объектов и таблиц данных
Моделирование структуры программы помимо демонстрации логики взаимодействия экранов косвенно позволяет решать еще одну задачу – оценивать объем работ на проработку документа спецификации. Ведь каждый введенный пользовательский экран потребует описания полей данных и алгоритма их заполнения. Например, если программа описывается трехуровневой структурой, то в спецификации потребуется задать:
Описание содержательной части разработки в функциональной спецификации начинается с селекционного экрана. Каждое поле селекционного экрана помимо названия, типа и размерности данных будет содержать признаки:
Рис. 17. Пример селекционного экрана: а) описание в спецификации на разработку; б) реализация экрана в SAP ERP на примере транзакции MRBR
Отличие вида поля «параметр» и «диапазон значений» заключается в том, что первый позволяет вводить только одно единственное значение, в то время как второй – множество. Пример описания селекционного экрана и его возможная реализация в системе SAP ERP дан на рис.17.
При описании полей экранов выбранных и обработанных данных указываются все те же название, тип и размерность данных, кроме того задаются функции обработки, такие как: фильтрация, сортировка, суммирование, подсуммирование и др. (рис.18).
Рис. 18. Пример экрана выбранных данных: а) описание в спецификации на разработку;
б) реализация экрана в SAP ERP на примере транзакции MRBR
Определив поля селекционного экрана и экрана выбранных данных, переходят к заполнению последнего. Алгоритмы заполнения полей можно описать следующими способами:
Описание алгоритма в виде блок-схемы достаточно трудоемко, поэтому осуществляется только для задания самых важных и сложных моментов работы программы. Использование языка структурированных запросов к данным (SQL, Structured Query Language) позволяет единообразно описывать алгоритмы, что немаловажно для международных проектов внедрения КИС. И, наконец, произвольное текстовое описание применяется достаточно редко и чаще всего новичками.
Как было сказано ранее, большая часть программ в ERP-системах представляются в табличном виде. Каждая таблица состоит из столбцов, заданных названиями полей, и строк, определяющих значение каждого поля. Базовый принцип заполнения полей экрана выбранных данных сводится к следующему (рис.19):
Рис. 19. Принцип заполнения полей экрана выбранных данных
С одной стороны заполнение полей экрана выбранных данных осуществляется на основе входных параметров селекционного экрана, что представляет собой некое сопоставление; с другой – определяются главные и прочие таблицы данных, используя алгоритмы выборки. Объединяя первое со втором, получаем процедуру по описанию логики заполнения второго экрана программы. Более того, поля экранов могут заполняться статическими значениями, хранимыми в таблице баз данных, и динамическими, рассчитанными по определенной формуле на основе статических.
Подробнее рассмотрим пример на рис.20. Описание логики заполнения полей экрана выбранных данных можно разбить на три части:
Рис. 20. Пример описания алгоритма заполнения полей экрана выбранных данных
в спецификации на разработку
Если программа относится к категории «С – программа обработки данных», экран выбранных данных вероятнее всего будет содержать кнопку, изменяющую информацию системы. Функционирование кнопки описывается схожим образом, для чего задаются:
Рис. 21. Пример описания функциональной кнопки для транзакции
Пример описания кнопки дан на рис.21. Из рисунка видно, что процедура, отвечающая за изменение, применяется к позициям экрана выбранных данных, имеющих статические или динамические значения. Полученные выходные результаты будут в последующем отображены в экране обработанных данных.
Задание полей и алгоритмов заполнения экрана обработанных данных ведется аналогично экрану выбранных данных с тем лишь отличием, что выборка осуществляется с использованием информации, полученной при срабатывании функциональных кнопок (рис.22).
Рис. 22. Пример экрана обработанных данных: а) описание правила заполнения в спецификации на разработку; б) реализация экрана в SAP ERP на примере транзакции MRBR
Моделирование сложных программ потребует больших усилий, в частности, если речь идет о создании программной С-разработки с нуля, возникнут дополнительные шаги проектирования и ведения таблиц баз данных, для чего необходимо:
Разделение этапов проектирования классов и таблиц баз данных сделано неслучайно. Дело в том, что на начальных шагах моделирования детальная информация о составе данных может отсутствовать, более того с течением времени она изменятся. Нормализовывать таблицы нужно тоже с умом: несмотря на то, что 3НФ постулирует вынесение не ключевых атрибутов, зависящих от других не ключевых полей в отдельные таблицы [18], на практике данный принцип часто игнорируют в угоду получения минимальной информативной отчетности напрямую из таблиц.
3.3. Способы поиска таблиц баз данных в SAP ERP
Продумав логику взаимодействия экранов программы, предварительное содержание каждого из экранов, а также структуру проектируемых баз данных, процесс подготовки к написанию спецификации завершается определением стандартных таблиц данных ERP-системы, из которых в последующем будет выбираться вся необходимая информация.
Применительно к системе SAP ERP доступны следующие способы выявления стандартных таблиц баз данных [19]:
кроме того вне зависимости от прикладной информационной системы большая часть таблиц баз данных, а также их ER-диаграммы (Entity Relationship, диаграммы взаимосвязи таблиц) доступны в сети интернет. Ссылка на 2-ю часть статьи.