Лекция
№ 7
Анализ
и постановка задачи
Уже на
стадии постановки задачи должны быть определены цели этапов проекта и самого
проекта, включая критерии их выполнения. Цели должны быть
сформулированы предельно четко и ясно (по возможности, удовлетворяя критериям SMART: конкретность, измеримость,
достижимость, актуальность, установка конкретного срока.
Под интегрированной системой управления понимается
система управления, использующая совокупность современных программно-аппаратных
средств, информационных технологий и экономико-математических методов для
регулярного решения задач управления производственно-экономической
деятельностью предприятий и коммерческих организаций.
Интегрированная система управления является сложной
системой управления, включающей в свой состав отдельные модули
(подсистемы).
Модуль
– часть системы, выделенная по определенному признаку, отвечающему конкретным
целям и задачам управления. В рамках этих задач он может рассматриваться как
самостоятельная система.
1.
Информационное обследование предприятия
Анкетирование Основными целями информационного обследования
являются детальное описание требуемых бизнес-процессов, подготовка предприятия
заказчика к внедрению системы и уточнение графика выполнения работ по внедрению
системы по срокам и видам работ. Информационное обследование осуществляется по
определенной методике, предусматривающей три ключевых этапа:
‒ Сбор первичной информации (анкетирование,
интервью и др.).
‒
Систематизация и анализ информации.
‒ Представление собранных данных (в формате
отчета) для согласования результатов обследования с заказчиком проекта.
Основные активности этапа:
‒ Определение даты начала работ, назначение
руководителя работ и ответственных представителей заказчика по каждому
подразделению предприятия, в которых проводятся работы по обследованию
бизнес-процессов, издание приказа о начале работ.
‒
Определение основных характеристик предприятия командой исполнителя.
‒
Утверждение приказа об информационном обследовании бизнеспроцессов
предприятия с назначением руководителя проекта от заказчика.
‒
Формирование графика проведения собеседований по анкетам с указанием даты,
места и участников встречи.
‒ Проведение интервьюирования для описания бизнес-процессов
(включая сквозные) с указанием ответственных.
‒ Анкетирование основных подразделений.
‒ Подготовка отчета для заказчика о
результатах обследования с его последующим согласованием и утверждением.
Среди предоставляемых заказчиком анкет
информационного обследования:
‒ Опросники для
высшего руководства.
‒ Опросники
руководителей подразделений.
‒ Опросники
специалистов: ведущих специалистов, сотрудников отделов, служб, главного
бухгалтера, сотрудников бухгалтерии (в случае внедрения финансовых или
интегрированных с ними систем).
Анкета для
высшего руководства предназначена для определения проблемных зон в
функциональном взаимодействии подразделений и информационном обмене,
затрудняющих процесс принятия управленческих решений для руководства
предприятия. Данная анкета может быть заполнена генеральным директором,
финансовым директором, коммерческим директором, техническим директором и
другими руководителями аналогичного ранга. Внимательное заполнение анкеты, а
также предоставление полной и точной информации поможет консультантам лучше
структурировать те проблемы на предприятии, которые могут быть решены с их
помощью. Анкеты руководителей бизнес-подразделений
создаются в целях определения проблемных зон в информационном обмене и
функциональном взаимодействии подразделений и с точки зрения определения
текущей ситуации и выявления потенциальных областей для улучшения он является
наиболее показательным.
Помимо
анкет и интервью с ответственными от подразделений, используются в качестве
источников информации также следующие передаваемые
заказчиком документы:
‒
Информационный буклет (рекламный проспект) об истории и основных направлениях
деятельности предприятия.
‒ Схема
организационной структуры.
‒ Положения о подразделениях, отделах.
‒ Учетная политика предприятия.
‒
Стандарты качества. ‒ Стратегия развития.
‒
Документация по используемому ПО.
И
наконец, анкеты для специалистов
призваны выявлять зоны ответственности сотрудников, основные «узкие места»
процессов, с которыми им приходится сталкиваться при работе. Определяется,
каким образом специалисты организуют свою ежедневную деятельность, с какими
системами / данными работают.
Также
вопросы анкеты помогают сформировать точку зрения
сотрудников на потенциальные возможности улучшения процессов как в области
их ответственности, так и в масштабах всей организации.
Прочие
методы сбора информации
Как и в случае экспресс-обследования,
помимо интервью с ответственными от подразделений и анкет на этом этапе
используется значительный объем документальных источников информации:
‒ Все
запрашиваемые первичные документы предприятия.
‒ Стандарты предприятия.
‒
Положения о подразделениях, должностные инструкции, штатное расписание,
стандарты предприятия.
‒ Нормативно-справочная информация.
‒
Бизнес-план и / или стратегия развития предприятия.
‒ Имеющиеся на предприятия аналитические
отчеты, результаты маркетинговых исследований и т.п.
‒
Финансовые отчеты, балансы и т.п.
В результате интервью должны быть:
‒
выявлены все внешние объекты, с которыми предприятие взаимодействует,
технологии взаимодействия со стороны предприятия, а также информационные и
материальные потоки, обеспечивающие эти взаимодействия;
‒ выявлены реальные технологии работы
предприятия;
‒
определены реальные функции подразделений и их взаимосвязи и взаимозависимости,
информационные потоки;
‒
идентифицированы и специфицированы все информационные хранилища, в т.ч. и
бумажные (картотеки, архивы);
‒ оценены используемые на момент проведения
обследования средства автоматизации и программное обеспечение
как в структурных подразделениях, так и на предприятии в целом.
По результатам проведенных работ
исполнителем должна быть подготовлена и передана
заказчику бизнес-модель предприятия (с диаграммами сквозных
бизнес-процессов), а также сформирован
план мероприятий по внедрению системы.
В типовом виде он содержит:
‒ Цели и задачи внедрения.
‒ Организационные мероприятия.
‒
Рекомендации по реорганизации необходимой организационной структуры для
поддержки системы.
‒ Распределение функционально-рабочих мест
системы у предприятия-заказчика.
‒
Требования к аппаратному и системному программному обеспечению локальной сети
предприятия-заказчика.
‒ Пуско-наладочные работы (состав, сроки).
‒ Этапы ввода системы в эксплуатацию.
‒ Ориентировочный план-график проведения работ
по внедрению системы на предприятии заказчика (в относительных датах).
‒ Ориентировочная стоимость поставки и
внедрения системы.
И конечно, переход к следующему этапу невозможен,
если не определены цели внедрения системы. Вне зависимости от
того, приобретается ли «коробочное» решение или начинается разработка с нуля,
очень важно на данном этапе уточнить с заказчиком и спонсором проекта список
основных стейкхолдеров и достичь в переговорах с ними
компромисса, так как у всех заинтересованных лиц могут быть очень разные
представления о назначении и целевом использовании системы, как и о ее
масштабах. В дальнейшем полученная информация уточняется в ходе фазы
проектирования и становится основой для формирования технического задания,
которое должно быть максимально проработанным со всеми участниками проекта,
ведь именно на первых двух стадиях совершается большинство ошибок, которых
можно избежать при применении более формальных методов анализа.
2. Описание бизнес-процессов
На этом этапе формируются описания законченных
бизнес-процессов, участие в котором могут принимать одно или несколько
подразделений.
ПРИМЕР
Определяются основные активности процесса.
Производство:
‒
планирование выпуска и производственных мощностей;
‒ планирование обеспечения ресурсами (ТМЦ,
услуги и работы, трудовые ресурсы, энергия, прочее);
‒ организация производственного процесса
(подготовка документов для производства);
‒ учет затрат на производство (основное,
вспомогательное)
‒ прямые производственные затраты, косвенные
(общепроизводственные);
‒ учет выпуска готовой продукции и
незавершенного производства;
‒ контроль над выполнением производственной
программы (диспетчеризация производства);
‒
анализ производства (отчетность);
‒ основные
проблемы на данном функциональном участке и рекомендации по их решению
(проблема – причина – выход).
Основная
цель моделирования процессов – их документирование и последующее осуществление
функционального анализа на предмет поиска «узких» мест процессов и возможностей
для их совершенствования. Полученные результаты будут
использоваться при формировании функциональных требований к системам, а также
при реинжиниринге бизнес-процессов. Далее
отображаются также основные действующие лица, документооборот, поддерживающие
информационные системы и прочие элементы процессов, уже в графическом виде (в
том числе UML-диаграммы, нотации BPMN и EPC). Подобное моделирование отдельных
предметных областей и процессов позволяет сформировать системное представление
о деятельности организации.
Основные нотации / методологии
моделирования BPMN
Нотация
моделирования бизнес-процессов BPMN (Business Process Modeling Notation) была впервые представлена публике еще в 2004
году и описана консорциумом Object Management Group. В основе
управления процессами в BPM идея, что сама стратегия управления опирается на
три основные методологии: моделирования бизнес-процессов, анализа и
оптимизации. В свою очередь, их поддерживает ряд инструментальных средств, в
частности:
‒ Для разработки стратегии, описания, анализа,
документирования.
‒ Для информационной поддержки
бизнес-процессов.
‒ Для поддержки потока работ (Workflow management).
BPMN с
самого начала создавалась как нотация, подходящая для применения любым
пользователем – от бизнес-аналитиков
и разработчиков до руководителей, менеджеров бизнес-процессов и просто рядовых
сотрудников подразделений. Она объединяет различные точки зрения на
бизнес-процесс, тем самым стандартизируя модель. ПРИМЕР В официальном полном описании нотации
BPMN указывается, что для разработки
первой версии модели были объединены концепции и некоторые объекты следующих
диаграмм/нотаций:
‒
Диаграммы активности UML (universal modeling language).
‒ Диаграмма
потоков активностей и принятия решений ADF (activity decision flow).
‒
Диаграмма событийных цепочек процесса EPC (event-driven
process chain),
‒ Нотация функционального моделирования IDEF (Icam DEFinition for functional modeling)
. ‒ Другие модели (UMLEDOC Business Processes, RosettaNet,
LOVeM).
|
Группы
объектов |
Описание |
|
Действия
|
При
помощи объектов Действия описываются задачи (бизнес-правила, сценарии,
задачи-сервисы, задачи отправки сообщений и другие). Задачи затем
детализируются, в том числе за счет маркеров действий (сценариев действий) и
определения потоков (порядка и условий выполнения действий). |
|
События
|
События
в BPMN, как и в некоторых других нотациях, относятся к категориям начальных,
промежуточных и завершающих. К событиям относятся: отправка и получение
сообщений, таймеры, ошибки, сигналы, остановы и другие виды событий. По сути событие является индикатором требующего дальнейшего
участия пользователя происшествия, что возможно организовать НЕ прерывая
процесса (в отличие от предыдущих версий нотации). |
|
Логические
операторы |
Логические
операторы определяют порядок наступления событий процесса при ветвлении и
слиянии / синхронизации. |
|
Данные
|
Стандартные
объекты данных (сообщения, хранилища, коллекции объектов), которые могут
использоваться различными действиями ГЛАВА 2. Жизненный цикл ИС |
|
Хореография
|
Понятие,
впервые появившееся именно во второй версии нотации BPMN. Его основная идея в
отражении задач взаимодействия (обмена сообщения) между участниками (двумя и
более). Хореография по сути представляет собой
принципы поведения между различными пулами (а не внутри одного) без выделения
единого центрального контроллера процесса. |
|
Диалоги
/ взаимодействия |
|
|
Роли
|
Благодаря
группе объектов Роли определяются: ‒ Распределение обязанностей
участников процесса. ‒
Информационные потоки между ними. ‒ Порядок обмена этими сообщениями. |
|
|
|
|
|
|
В 2010 году была опубликована
версия BPMN 2.0, созданная при сотрудничестве многих исследовательских групп, в
том числе консорциума Object Management
Group, Института Хассо Платтнера (Hasso Plattner Institut – Потсдам,
Германия), университета Гумбольдта (Берлин, Германия), университетской
инициативы Signavio. В 2013м версия BPMN 2.0.1 была
принята как международный стандарт ISO/IEC 19510:2013 Информационные
технологии. Модель и нотация процесса менеджмента объекта в групповом бизнесе.
Среди основных понятий и групп объектов в BPMN:
UML
(Unified modeling language, универсальный
язык моделирования)1 является методологией объектно-ориентированного подхода,
представляющей набор диаграмм для проектирования информационных систем.
|
Диаграмма
вариантов использования / прецедентов (Use case diagram) Описание
«вариантов использования» системы (по сути – выполняемого ей набора функций).
Все варианты использования в подобных диаграммах должны относиться к тому или
иному действующему лицу (актору), так как
определяют для них варианты / сценарии поведения. Такие диаграммы применимы
при описании определенных требований к системе, описывая как ее объекты, так
и объекты предметной области. ПРИМЕР
Система бухгалтерского учета. Сотрудник бухгалтерии: «Сформировать счет за
поставку товара для контрагента А». Главный
бухгалтер: «Согласовать счет», «Сформировать сводный отчет по расчетам с
контрагентом А за период 6 мес.» |
|
|
Диаграмма
развертывания (Deployment diagram) Диаграммы
топологии предназначены для определения аппаратных средств, топологии
проектируемой системы ПРИМЕР
Сервер приложений, СУБД, рабочие станции
|
|
|
Диаграмма
состояний (statechart diagram) Диаграмма,
описывающая все возможные состояния в модели поведения системы ПРИМЕР
Опрос Web-ресурса Ожидание подключения к серверу |
|
|
Диаграммы активности (activity diagram) Определение
основных бизнес-процессов объекта, последовательности их реализации,
ветвлений при принятии решений, дальнейшей синхронизации процессов ПРИМЕР Получить заказ, Выполнить заказ, Сформировать счет,
Отправить счет |
|
|
Диаграмма последовательности (sequence diagram) Данная
диаграмма представляет собой единый процесс взаимодействия между объектами, с
фокусом на переносе активностей от одного объекта к другому и
последовательности подобных действий. |
|
|
Диаграмма сотрудничества (collaboration diagram) Данная
диаграмма отражает взаимодействия между различными действующими лицами в
процессе выполнения процесса. |
|
|
Диаграмма классов (class
diagram) Логическое представление системы через
определение основных классов (например, Человек, Студент, Профессор) и
отношений между ними (например, наследование)
|
|
|
Диаграмма компонентов (component diagram) Определение
основных модулей системы и связей между ними
ПРИМЕР
Управление отношениями с потребителями, Управление продажами, Управление
финансами |
|
UML версии 2.4.1 был также принят в качестве
международного стандарта моделирования. ISO/IEC 19505:2012. Информационные
технологии. Унифицированный язык моделирования группы по управлению объектами
(OMG UML).
IDEF
IDEF (Icam (Integrated computer-aided manufacturing) DEFinition for functional modeling) представляет
собой семейство стандартов описания и отображения бизнес-процессов.
·
IDEF0, отображающая
процесс на уровне функций.
·
IDEF1, фокусирующая
на информационных потоках.
·
IDEF1X для разработки реляционных баз данных.
·
IDEF3, моделирующая
технологические процессы как следующий уровень после IDEF0.
·
Прочие (реже применяющиеся методологии
IDEF):
Ø IDEF2
для динамического моделирования систем.
Ø IDEF4
для построения объектно-ориентированных систем.
Ø IDEF5
для онтологического исследования сложных систем.
Ø IDEF6,
акцентирующая внимание на процессе создания модели (обстоятельствах и причинах
выбора того или иного метода моделирования).
Ø IDEF7
для аудита информационных систем.
Ø IDEF8
для разработки пользовательских интерфейсов.
Ø IDEF9
для определения бизнес-ограничений
при сценарном проектировании информационных систем.
Ø IDEF10
– IDEF14 – методы в области проектирования компьютерных сетей, архитектуры
внедрения и прочих предметных областей, которые были определены как необходимые
и востребованные, но разработка которых не была
завершена.
Язык структурного анализа SADT (structured analysis and design technique). Рассмотрим
наиболее распространенные диаграммы (а именно:
IDEF0 и IDEF3) подробнее.
IDEF0
IDEF0
представляет процесс в виде иерархической структуры функциональных блоков.
Функциональный блок представляет собой функцию
(например, «Производить услуги», «Разработать план производства», «Выставить
счет»), к которой относятся интерфейсные дуги четырех
типов (Вход, Выход, Управление, Механизм). Входом и выходом функции могут
являться как различные реальные объекты (детали, материалы), так и потоки
информации (данные о заказах, аналитика продаж). Управление определяет все
стандарты, методологии, распоряжения и прочие регламентирующие документы, а
Механизм – поддерживающие выполнение функции информационные системы, сотрудники
и ресурсы. IDEF0 в обязательном порядке требует указания как минимум одной
управляющей и одной исходящей интерфейсной дуги, что объясняется с точки зрения
необходимости для каждой функции иметь определенные правила выполнения и
определенный результат, иначе смысла в функциональном блоке просто не будет.
IDEF0 используется не только для иллюстрации процессов предприятия, но и в
целом для описания схемы его функционирования, с какими ресурсами компания
работает, от чего зависит и какой итоговый результат производит. Однако в
некоторой степени содержание функциональных блоков IDEF0 остается «черным
ящиком», в связи с чем и проводится построение
дополнительны схем процессов, уже в нотации IDEF3.
IDEF3
IDEF3 предназначена для документирования процессов системы,
последовательности их операций, детализирующих функции, описанные в IDEF0.
Данный подход более структурированный, чем IDEF0, и определяет схемы
последовательности процессов, их ветвления и слияния, что также полезно в
случае использования модели для дальнейшей работы уже с методами имитационного
анализа. IDEF3 оперирует понятиями «единиц работы», которые объединяются по
принципу временного предшествования либо использования результатов одной
единицы работы в качестве входных потоков для другой.
ПРИМЕР Функция «Анализ
сведений о приемке товара». Текстовое описание. Старший кладовщик направляет
упаковочный лист в отдел закупок. В отделе закупок анализируются сведения о
приемке товара. Если фактическое количество прибытия товара имеет отклонение в
пределах нормы, то производится расчет себестоимости товара. Составляется 3
вида документов: расчет себестоимости товара направляется на склад; расчет
себестоимости с раскладкой себестоимости по поставщикам ТМЦ и услуг направляется
в финансовый отдел; расчет себестоимости без раскладки по поставщикам
направляется начальнику отдела продаж. Если есть значительные ошибки (нарушение
сроков годности, недостача), то проводится анализ причин, выявляются виновные,
предъявляются претензии. Графическое описание.
EEPC
Нотация eEPC (Extended Event-driven Process Chain, расширенная событийная цепочка процессов),
предполагает описание алгоритма действий, выполняемых отдельными
организационными единицами, что позволяет сформировать общий сценарий процесса
как последовательность отдельных шагов. Основными объектами диаграммы eEPC являются следующие элементы:
|
Тип объекта |
Описани |
Графическое обозначение |
|
Событие |
Состояние
внешней / внутренней среды, являющееся также обязательным условием начала и
окончания выполнения функции. Конечные события могут также быть начальными
событиями для другого процесса. |
|
|
Логическое
правило |
Правила
выполнения функции (если наступает только одно из событий или обязательно оба
события) и правила наступления событий при выполнении функций (по сути –
правила слияния и разделения ветвей процесса) |
|
|
Функция
|
Описание
элемента работы, который представляет собой один этап процесса |
|
|
Интерфейс
процесса |
Внешний
(по отношению к текущей диаграмме) процесс или функцию. Используется для
указания взаимосвязи процессов (как для логической последовательности:
следующий / предыдущий процесс, так и для обозначения направления передачи
объекта) |
|
|
Объекты
организационной схемы |
Обозначение
организационных единиц (должностей, подразделений, ролей) – исполнителей,
владельцев или участников функций. Бизнес-роли в данном случае рассматриваются как требующие полномочий для
управления функциями |
|
eEPC
не случайна названа «расширенной» диаграммой – на
практике в модели такого вида могут также включаться другие объекты, например
·
Товарно-материальные ценности.
·
Бумажные и электронные документы.
·
Продукты (используемые и производимые).
·
Объекты информации.
·
Информационные системы и их отдельные модули /
функции.
·
Базы данных.
·
Цели (которые поддерживаются конкретной
функцией).
·
Места выполнения (например, производственный
цех № 4).
·
Другие элементы описания.
Между всеми объектами в обязательном порядке определяются связи,
например, «создает» (документ), «распределяет» (задание между сотрудниками),
«использует» (информационную систему 1С), «выполняет» (функцию выполняет
менеджер), «принимает решение», «обеспечивает», «является владельцем» и многие
другие.
ПРИМЕР
Текстовое описание.
На вход
процесса поступает запрос от клиента, который должен быть обработан.
Ответственность за выполнение данной функции возлагается на отдел продаж. По
результатам обработки запроса будет сформирован заказ в системе 1С.
Графическое описание.
Таким образом, благодаря уровню процедур объединить
на нем все объекты, задействованные в разных представлениях (документы,
информационные системы, организационные единицы и должности, процессы), а
значит составить интегрированную картину процесса. Она, в свою очередь, может в
дальнейшем использоваться либо как основа для As-Is
–анализа, либо для последующей доработки и автоматизации
как самого процесса, так и управления им с точки зрения достижения целевых
показателей эффективности.
3. Программные продукты моделирования деятельности организации
У использования программных продуктов,
поддерживающих ту или иную методологию описания процессов, в масштабах всей
компании есть несколько неоспоримых преимуществ. Во-первых, это помогает сузить
спектр специализированных решений для моделирования, навыки работы с которыми
необходимы сотрудникам компании, как и спектр необходимых для детального
изучения методологий. В свою очередь, это расширяет потенциальные границы
использования на предприятии созданных моделей процессов. Во-вторых,
программные решения позволяют использовать единый внутренний репозиторий объектов, который способствует связности
моделей и проведению их верификации. Для перевода информации о процессах
организации в цифровой вид и моделировании в конкретной нотации описания
процессов необходим следующий набор активностей:
·
Организация рабочей группы и проведение ее
заседания в целях анализа имеющихся данных по бизнес-процессам, их объектов и
существующих взаимосвязях.
·
Создание предварительных моделей существующих
процессов (в состоянии «как есть»), их последующее обсуждение, доработка и
согласование.
·
Преобразование данных о процессах в вид
моделей выбранной методологии описания в виде «как есть».
·
Создание, доработка и утверждение моделей вида
«как должно быть».
·
Непрерывный анализ, мониторинг и оптимизация
процессов.
Поддерживать системный и структурный уровни
рассмотрения организации, а также модели бизнес-процессов позволяют
CASE-технологии, реализованные в том числе в виде
отдельного класса программного обеспечения (Computer-Aided
Software / System Engineering). Данные системы: представленные CA ERWin Data Modeler
(бывшие BPWin и Erwin), IBM
Rational Rose и некоторыми
другими продуктами, позволяют системным аналитикам и командам разработчиков
после общения с бизнес-заказчиком
сформировать проект описания деятельности компании и в дальнейшем перейти к ее
автоматизации. Завершая разговор о различных моделях описания процессов и
инструментальных средствах, приведем сравнительную таблицу возможностей
основных платформ моделирования.
CA ERWin
Data Modeler
Комплекс
CASE-средств, среда моделирования и коллективной работы с данными,
проектирования и генерации баз данных. Интеграция процессов и данных (с IDEF0,
DFD, IDEF3), Проверка и оптимизация дизайна баз данных, доступ к метаданным и
их интеграция.
Software AG ARIS (ранее IDS Scheer ARIS)
Моделирование
организации, процессов, данных, функций, продуктов и услуг. Поддержка создания
ИС от анализа требований до разработки (через интерфейсы экспорта моделей в
средства разработки). Дополнительные возможности работы с системой
сбалансированных показателей, операционными рисками, стандартами качества
IBM Rational
Rose
Проектирование приложений ИС с возможностью
генерации баз данных и исходного кода. Реализация UML-диаграмм (состояний,
классов, взаимодействия и других).
Microsoft
Visio
Один из
первых инструментов создания графических диаграмм. Со временем расширяя репозиторий доступных моделей и новых объектов, он
основывается на отдельных наиболее распространенных видах диаграмм, хотя и не
предоставляет автоматизированных инструментов их анализа.
ARIS EXPRESS & ARIS
PLATFORM
Архитектура
интегрированных программных систем ARIS (ARchitecture of Integrated Information
Systems) – инструментальная система моделирования
бизнеса, разработанная компанией IDS Scheer AG.
ARIS и как методология, и как платформа обеспечивают
проектирование, внедрение и управление бизнес-процессами
как в процессе повседневной работы, так и для целей анализа, оптимизации и реинжиниринга бизнес-процессов.
Модель организации в ARIS может быть определена
следующим образом:
Модель
организации – совокупность взаимосвязанных /
взаимодополняющих графических моделей, которая адекватно описывает моделируемые
предметные области деятельности организации.
Таким образом, ARIS как методология позволяет
моделировать такие подсистемы предприятия, как организационная, функциональная,
информационная, процессная и подсистема входов / выходов. Они формируются на
трех уровнях описания, иерархически идущие от анализа проблем бизнеса к
конкретной реализации при помощи ИТ:
‒
Требования (семантические модели).
‒
Спецификации (бизнес-описания
с ориентацией на информационные технологии).
‒ Реализация (модели, еще более детализирующие
спецификации на уровне информационных технологий).
Для каждого
из представлений программный продукт ARIS предусматривает различные виды
диаграмм.
ПРИМЕР Модель организационной структуры будет
содержаться в представлении Организация, а модель знаний персонала будет
доступна в представлении Данные.
Для категории Продукты / Услуги существует
уровень требований, примером которого может служить формируемое Дерево
продуктов.
Все базовые
возможности ARIS реализованы в программном продукте ARIS Express,
полнофункциональная версия которого находится в свободном доступе. В ней
пользователи могут создавать 9 базовых типов диаграмм:
‒
Организационная диаграмма.
‒
Диаграмма данных ERM.
‒ Диаграммы BPMN 2.0.
‒
Процессный ландшафт (цепочка добавленной стоимости VACD).
‒ Системный ландшафт (диаграмма компонентов).
‒
Иерархическая диаграмма активностей (whiteboard).
‒
Диаграмма бизнес-процессов EPC.
‒
Диаграмма ИТ-инфраструктуры (сети).
‒
Диаграмма общего вида.
Также представляются такие
возможности, как печать моделей, экспорт в форматах PDF & EMF,
создание собственных шаблонов диаграмм, панель инструментов моделирования, онлайн-поддержка, а также автоматическая генерация моделей
из определенных форматов документов и импорт MS Visio.
Гораздо более расширенным с точки зрения функциональности
является семейство программных продуктов ARIS Platform
(в 2013 году – ARIS
Architect
& ARIS Designer).
Список доступных для создания диаграмм гораздо больше и он исходит из идеи, что
любая организация может быть описана с помощью целой иерархии моделей (от
верхнего уровня цепочки добавленной стоимости VACD до диаграмм конкретных
процедур и ресурсного окружения). В нем доступны также центральный репозиторий моделей, версионность,
поддержка множества языков, многопользовательская работа, версионность,
конструктор отчетов WYSIWYG, конфигурируемые мета-модели и многие другие возможности. Однако
помимо стандартной функциональности формирования моделей платформа ARIS
содержит дополнительные расширения:
|
Дополнительные
инструменты / возможности |
Предоставляемые
преимущества |
|
Процессная
аналитика |
Визуализация
проблем производительности Получение отчетов / оповещений о достижении
критических отметок показателей процессов Мониторинг данных, процессов и их
ключевых индикаторов (например, функционально-стоимостной анализ затрат) |
|
Управление
рисками |
Управление
бизнес-операциями, рисками
и требованиями, контроль исключений |
|
Управление
политиками и соответствием требованиям регуляторов |
Формирование
карт политик в бизнес-контексте
с разграничением зон ответственности Сочетание политик управления
требованиями, рисками и процессами Ведение журнала аудита с возможностью
формирования сложных отчетов (в том числе, по контрольным панелям) |
|
Управление
взаимодействием: создание рабочей платформы коллаборации
|
Организация
общих обсуждений процессов / приложений / данных Представление моделей
процессов в формате web-страниц Публикация моделей процессов в интранет-сети компании Возможность для специалистов
компании предложить свои улучшения в процессах |
|
Симуляция
|
Возможность
«прогона» (симуляции) моделей BPMN 2.0 и EPC для выявления различий моделей As-Is и To-Be Получение
статистики и сводной информации по результатам симуляции моделей в режиме
реального времени Возможность проведения сценарного анализа «Что если» для
определения степени зависимости результата и показателей процессов от
определенных факторов/групп факторов |
|
Моделирование
бизнесправил |
Возможность
определения логики бизнес-правил и связывания
сформированных с их помощью структурированных моделей с электронными
таблицами (например, для анализа стоимости процесса) |
|
Управление
оптимизацией бизнеса |
Интеграция
информации о структуре и значениях ключевых показателей эффективности
процессов, моделях бизнес-процессов, информации о центрах затрат для
поддержки принятия стратегических решений Все эти возможности представлены в
виде дополнительных расширений к ARIS Architect&Designer:
|
Кроме того, для формирования специфических
аналитических отчетов, регламентов процессов, создания базы моделей по спецификациям возможно использовать технологию ARIS Script и писать сценарии (подпрограммы) на языке SAX Basic.
CA ERWIN DATA MODELER
Среди
ключевых функций:
‒ Визуализация структур данных.
‒ Создание проектов баз данных (по графическим
моделям).
‒ Определение стандартов (например, шаблоны
моделей).
‒ Сравнение моделей и баз данных.
‒ Отчетность и публикация (в
том числе в HTML
-виде с экспортом
изображений графических моделей и метаданных).
Данный программный продукт интегрирует возможности BPWin и ERWin, обеспечивая также
создание логических и физических моделей и трансформацию между ними.
IBM RATIONAL ROSE
Семейство
продуктов IBM Rational Rose,
предлагая средства разработки приложений, основывается на Unified
Modeling Language:
‒ Rational Rose Enterprise.
‒ Rational
Rose Modeler.
‒ Rational Rose
Technical developer (Java/C/C++) & Developer for Java/UNIX/Visual Studio.
Одним из ключевых преимуществ IBM Rational Rose является
возможность не просто моделирования, но и создания кода на основе UML,
значительно упрощая и ускоряя процесс разработки ПО и формирования
документации. В этом программном продукте доступно создание концептуальных и
физических моделей структуры данных, а также диаграмм классов / состояний /
сценариев и других моделей UML, что крайне важно в процессе разработки. Среди
основных компонент программного продукта:
‒ Репозиторий.
‒
Графический интерфейс пользователя.
‒
Средства просмотра проекта (для перехода между диаграммами).
‒
Средства контроля проекта (автоматический поиск / устранение ошибок логики
диаграмм в ходе моделирования).
‒
Средства сбора статистики.
‒ Генератор документов.
Также отдельно доступен генератор кодов (для
определенных языков программирования) и анализатор с возможностью обратного
инжиниринга – формирования модели по исходному коду программы.
4 Сбор требований
Данная стадия подразумевает несколько аспектов – от
анализа задачи и специфики деятельности предприятия до анализа требований к
самой системе. Проектные спецификации и первые наброски технического задания на
данном этапе составляются по результатам проведенных интервью и в дальнейшем
уточняются для проведения оценки сроков, стоимости и содержания проекта в части
функциональности системы. Для того, чтобы правильно
сформировать стоящие перед целевой информационной системой задачи и определить
ее ключевые функции, критично проведение объективного и всестороннего сбора
требований. В IEEE Standard Glossary
of Software Engineering Terminology (1990)
понятие «требование» трактуется следующим образом.
«Требование – это: ‒ условия или возможности,
необходимые пользователю для решения проблем или достижения целей; ‒
условия или возможности, которыми должна обладать система или системные
компоненты, чтобы выполнить контракт или удовлетворять стандартам,
спецификациям или другим формальным документам; ‒ документированное
представление условий или возможностей для пунктов 1 и 2»
По сути, требования представляют собой определенный
набор входных данных, на основании которых проводится проектирование ИС.
Существует множество источников подобных данных (ведь в конечном итоге
необходимо создать систему для большого числа пользователей с различными
задачами), в связи с чем исходная информация является
достаточно противоречивой, неструктурированной, изменяющейся во времени. Однако
без этого этапа начать работу невозможно, так как именно согласие заказчика и
разработчика-исполнителя по вопросам объема / содержания работ, временных и
финансовых ограничений является критическим для выполнения проекта
автоматизации.
FURPS+
Для охвата
всех аспектов проектируемой ИС используется специальная классификация уровней
требований (FURPS+, изначально предложена в начале 1990-х годов специалистом Hewlett Packard Робертом Грейди). Сокращение FURPS является аббревиатурой и в
переводе на русский включает пять следующих аспектов:
·
Функциональность
·
Удобство использования
·
Надежность
·
Производительность
·
Поддержка.
Рассмотрим
каждый из уровней более детально.
‒
Functionality, функциональность
Ø Функциональные
возможности системы (например, управление маркетинговыми компаниями, анализ
клиентской базы, планирование контактов с клиентами, поиск по ключевым словам).
‒
Usability, удобство использования (характеристики
пользовательского интерфейса).
Ø Интуитивность.
Ø Эстетичность.
Ø Мультимедийность
(использование анимации, графики, видео и других форматов контента).
Ø Защита
от ошибок (человеческого фактора).
Ø Удобство
обучения.
Ø Полнота
системной документации и руководств пользователя.
Ø Легкость
получения справочной информации.
‒ Reliability,
надежность.
Ø Доступность
(минимально необходимое время бесперебойной работы системы – к примеру, 24 *
7).
Ø Точность
расчетов.
Ø Отказоустойчивость.
Ø Восстанавливаемость
системы (частота резервного копирования данных).
‒
Performance, производительность.
Ø Пропускная
способность (число одновременно работающих пользователей).
Ø Время
отклика системы (время реакции системы на совершенное пользователем действие).
Ø Время
восстановления.
Ø Масштабируемость
(к примеру, при увеличении числа пользователей в случае внедрения в других
филиалах).
Ø Потребление
ресурсов (к примеру, оперативной памяти).
‒ Supportability,
поддерживаемость.
Ø Ремонтопригодность.
Ø Адаптируемость
(скорость приспособления к условиям работы в конкретной среде).
Ø Совместимость.
Ø Легкость
установки.
Ø Конфигурируемость
(гибкость и оперативность изменения параметров системы, добавления новых ролей,
ограничения доступа, изменения функций).
Ø Локализация
(поддержка языков, валюты, настроек времени и дат выбранной страны).
Ø Поддержка
стандартов и требований регуляторов (например, поддержка SCORM – международного
стандарта обмена электронными курсами как требование к системе дистанционного
обучения).
‒
+, дополнительные ограничения.
Ø Ограничения
проектирования, design.
ПРИМЕР
Использование реляционной БД в качестве основной.
Ø Ограничения
разработки, implementation.
ПРИМЕР Ориентация на выбранную методологию
разработки (RUP/MSF), языки программирования (C#, Python,
…).
Ø Ограничения
на интерфейсы, interface (накладываются
пользователями или другими системами).
ПРИМЕР Использование определенных форматов данныхю
Ø Физические
ограничения, physical (например, к аппаратным
средствам и окружающей среде).
ПРИМЕР Требования к уровню влажности /
температурному режиму в комнате, где находится аппаратное обеспечение /
окружение системы.
Требования по Карлу Вигерсу
Все
вышеописанные требования (кроме первого, Functionality)
по сути являются нефункциональными (URPS+). Эти две
категории, в свою очередь, легли в основу другой классификации требований
(предложенной Карлом Вигерсом, известным лектором и
консультантом в области сбора требований и совершенствования процесса
разработки ПО). Среди функциональных требований он
выделяет три аспекта:
‒ Бизнес-требования, формулируемые
чаще всего спонсором / заказчиком проекта. Это цели, которые преследует
создание системы, какие преимущества необходимо таким образом достичь и какие
задачи решить. Таким образом, формируется общий образ и границы проекта,
которые также могут быть закреплены в уставе проекта.
ПРИМЕР
На уровне технического задания могут быть
сформированы требования к поддержанию бизнес-процессов. Так, в CRM-системе
можно выделить коммуникационные процессы (информирование и регистрация
и обработка обращений клиентов), отчетные и управленческие процессы.
‒ Пользовательские
требования. Решаемые системой задачи для различных категорий пользователей.
В данном случае требования могут быть представлены как в виде сценариев (user journey), алгоритмов (для
учета всех возможных вариантов действий), таблиц «событие-отклик».
ПРИМЕР
Могут также описываться ключевые роли, такие как:
«Оператор в банке», «Инвестор», «Партнер», «Клиент – физическое лицо», «Клиент
– юридическое лицо». В зависимости от выделяемых групп пользователей будут
различаться и их возможности в системе.
‒ Функциональные требования.
Определяемая функциональность системы, описываемая затем детально в техническом
задании для реализации разработчиком. Выделяемые Вигерсом
нефункциональные требования являются дополнительными аспектами, которые
необходимо принимать во внимание при разработке.
‒ Бизнес-правила. Требования
регуляторов (например, экологические нормы для производственных компаний),
промышленные стандарты, корпоративные стандарты и политики как налагаемые
внешней средой ограничения.
‒ Атрибуты качества.
Дополнительные требования к программному продукту, не относящиеся к задаваемой
классом систем функциональности (к примеру, для систем документооборота это
приѐм, хранение, пересылка, контроль исполнения
документов), а являющиеся необходимыми для эффективности системы
характеристиками (целостность, интероперабельность с
другими системами, интегрируемость).
‒
Ограничения. Преимущественно технические
ограничения, накладываемые условиями, в которых система должна быть
реализована
ПРИМЕР
Диктуемые целевыми параметрами производительности
протоколы, серверы приложений. При этом
источниками информации для функциональных требований могут служить описания
деловых (бизнес-) объектов (подразделений, должностей,
ролей, процессов, систем, носителей информации) с указанием их взаимосвязей, а
вид моделей и требования к ним определяются целями моделирования. В то же
время, нефункциональные требования создаются по результатам обследований
предприятия (интервью, анкетирование, наблюдение за типовым рабочим днем
сотрудника). Для описания необходимых шагов корректного формирования требований
обратимся к мировым практикам, описанным в сборнике SWEBOK. Данный документ
объединяет знания в области разработки ПО и будучи
разработанным комитетом сообщества IEEE Computer Society, призван определить набор знаний и рекомендуемые
практики по пяти основным стадиям ЖЦ, а также управлению конфигурацией,
качеством, ИТ-проектом, в том числе с описанием
процесса разработки ПО и используемых при этом методов и инструментов.
Этапы формирования
требований по SWEBOK
Согласно SWEBOK, работа
над требованиями предполагает 3 основные активности: их сбор (по результатам
интервью с представителями заказчика и обследования предприятия), анализ (в
т.ч. на полноту, непротиворечивость) и документирование (в виде сценариев использования,
user journeys, спецификаций
процессов).
Как правило, в сборе
требований со стороны заказчика принимают участие ключевые специалисты,
наиболее четко и ясно представляющих бизнес-деятельность своего подразделения и
грамотно формулируя требования для дальнейшей корректной их интерпретации
группой внедрения. Важно отметить, что практически в любой организации можно
встретить пользователей – экспертов, которые не просто готовы пользоваться
системой или даже принимать участие в ее улучшении, но хотят полностью
подстроить ее под свои нужды – а значит, важно соблюдать баланс и реалистично
представлять целесообразность добавления той или иной функции.
ПРИМЕР
В организации АВС с 300 сотрудников до внедрения
единой системы учет всех проектов вели вручную. Каждый проектный менеджер
отвечал за 10-15 видов активностей и либо заносил их в Excel
в свободном формате, либо пользовался онлайн-сервисами,
либо вообще просто все важные вещи записывал в свой ежедневник. После того, как
руководством было принято решение об интеграции всех данных в единую систему и
подключении к работе с ними филиала предприятия, эта идея была встречена
достаточно негативно. Помимо того, что сотрудники чувствовали, что их хотят
контролировать, мало кто представлял, что делать с
теми данными, которых будет не хватать для корректной работы с системой – или с
той информацией, которую никто кроме них не собирал (например, даты
промежуточных проектных встреч). Более того, одно и то же поле (например,
«перспективность проекта») не всегда заполнялось. К примеру, 60 % пользователей
заполняли без единого формата ввода:
‒ Менеджер А ставил
цифры от 1 до 5 (5 – высшая оценка, самый перспективный).
‒ Менеджер В ставил
цифры от 1 до 5 (но 5 – самый низкий приоритет, 1 – высший приоритет).
‒ Менеджер С выбирал
из вариантов «Перспективен для рынка Европы», «Перспективен для рынка США и
Китая», «Перспективен в России», «Под вопросом», «Не перспективен», вариант
«Другое»).
‒ Менеджер D же просто писал текстовые
комментарии, когда по его мнению конечный продукт,
разрабатываемый в ходе проекта, может выйти на рынок.
Однако из 50
сотрудников 5 основных подразделений двое специалистов в свое время разработали
по сравнению с остальными сложную систему ведения проектов, включающую макросы
для объединения данных нескольких Excel-файлов, и естественно, хотели чтобы именно их принцип организации данных был взят
за основу. Так, если они ввели собственные развернутые классификации зрелости и
перспективности проектов с drop-down меню и 15 варинтами ответа, именно ее они предлагали взять за основу
при определении формата соответствующих полей. Их мнение, безусловно, важно – и
если они начинают пользоваться системой (а не бойкотировать ее), «рядовые»
пользователи их подразделений, несомненно, присоединятся. Но насколько такая
система будет удобна для них, насколько уровень детализации и классификации,
«навязанные» коллегами, соответствуют потребностям массовых пользователей, в
особенности других подразделений и филиалов?
Важно помнить, что несмотря на важность получения поддержки ключевых
пользователей, в конечном итоге система внедряется именно в интересах всех
пользователей: именно их регулярная работа в системе и импортированные ими
данные являются базой для достижения эффективности системы.
Если, как уже было сказано,
компания-заказчик пришла к решению о самостоятельном сопровождении системы на
этапе эксплуатации, именно эти ключевые сотрудники будут принимать систему, для
чего необходимо отчетливо понимать, как те или иные действия пользователей
отразятся на работе системы и каким образом происходит движение информации в
ней. И говоря о движении информации, вновь вернемся к этапу анализа и
постановки задачи, на котором проводится описание автоматизируемых бизнеспроцессов и актуальных для них потоков данных.
Подготовка технического задания
Техническое задание
является достаточно регламентированным документом и рекомендации по его
формированию приведены в российском ГОСТ 19.201-78
«Техническое задание, требования к содержанию и оформлению» и ГОСТ 34.602-89
«Техническое задание на создание автоматизированной системы» (ТЗ на АС, которое
подробнее рассмотрено ниже).
Техническое
задание (проектное решение) на выполнение работ является
основным документом, определяющим порядок создания, настройки, доработки и
внедрения модуля системы (системы в целом).
‒ общие сведения о модуле / системе;
‒ назначение и цели настройки (создания,
доработки) модуля / системы (вид автоматизируемой деятельности (управление,
проектирование и т.п.) и перечень объектов автоматизации);
‒ характеристики
объекта автоматизации (наименования и требуемые значения технических,
технологических, производственно-экономических или других показателей объекта
автоматизации, которые должны быть выполнены в результате создания системы,
критерии оценки достижения целей ее создания);
требования:
·
к модулю / системе:
§
к структуре и функционированию;
§
к численности и квалификации персонала заказчика для работы с системой;
§
к надежность и безопасности /
отказоустойчивости;
§
к эксплуатации и техническому обслуживанию;
§
к безопасности информации;
§
к непрерывности бизнеса / сохранности информации при сбоях или авариях;
·
к функциональности:
Ø перечень
функций и задач, подлежащих автоматизации;
Ø сроки
реализации каждой функции (задачи);
Ø форма
представления выходной информации (и ее характеристики);
·
к проекту: информационное, программное,
техническое, организационное обеспечение, включая рекомендации по техническим
характеристикам стенда предприятия и рабочим местам пользователей;
·
к составу и содержанию работ:
§
по созданию и настройке системы (включая порядок и критерии ее приемки в
эксплуатацию);
§
по подготовке объекта автоматизации к вводу системы в опытно-промышленную и
промышленную эксплуатацию;
§
к проектной документации.
Техническое задание
систематизирует все функциональные и нефункциональные требования, тем самым
обеспечивая базу для дальнейших активностей по созданию и внедрению системы.