В реинжиниринге имеется еще одна составляющая - информационные технологии, поскольку они позволяют проводить реинжиниринг бизнес-процессов.
2.2 Проектирование корпоративных ПС
Обычный подход к анализу деятельности предприятия предполагает создание и анализ различных моделей (функциональных, процессных, информационных и других). Каждый аналитик, приступая к анализу системы, должен ориентироваться на некие стартовые условия, к которым относят:
- информация об объекте проектирования;
- знания о предметной области, в которой работает предприятие;
- знания об эталонных процедурах выполнения ключевых процессов в соответствии с международными или национальными стандартами;
- знания о методах и средствах моделирования и анализа систем;
- программные средства (инструменты) для моделирования и анализа;
- ограничения на создаваемую систему, связанные с реальными возможностями и существующими традициями предприятия. Достаточно просто суть моделирования можно представить в следующей последовательности:
- строится модель «as-is» (как есть), как снимок существующих бизнес-процессов;
- полученная модель анализируется на предмет выявления «узких» мест, лишних связей, недостающих цепочек и т.д.;
- строится модель бизнеса «to-bе» (как будет) и утверждается план работ по переходу от модели «as-is» к модели «to-be».
Требования к описанию бизнес-процессов.
Так как в построении модели предметной области, кроме аналитиков, принимают участие эксперты предметной области, то в применяемых моделях описание бизнес-процессов должно быть:
- простым и понятным экспертам предметной области;
- легко читаться и не быть при этом громоздким и сложным для уточнения;
- делаться в том же средстве, в котором на последующих этапах работ будет проектироваться система управления.
Системный анализ.
Этап системного анализа и проектирования является наиболее важным для успешного выполнения проекта, и поэтому может рассматриваться как один из факторов риска. В любом случае в формировании требований заказчика в той или иной степени участвуют и разработчик, и заказчик. На этапе системного анализа и проектирования при сравнительно малых затратах можно достичь следующих результатов:
- получить снимок бизнес- и информационных процессов для конкретного предприятия;
- выявить узкие места в бизнес-процессах и наметить пути их ликвидации;
- создать информационную и функциональную модель новой системы;
- сформировать список требований к новой или модернизированной ИС;
- выбрать методы и средства проектирования и реализации ИС;
- сформировать архитектуру системы;
- сформировать состав программных продуктов, которые необходимо приобрести в рамках создания ИС;
- составить предварительный укрупненный план проектирования и реализации базовой версии ИС;
- оценить трудозатраты разработки новой ИС;
- составить технико-экономическое обоснование.
При этом необходимо учитывать следующие особенности, характерные для крупных проектов:
- "сложность описания (достаточно большое количество функций, процессов, элементов данных и сложные взаимосвязи между ними), требующая моделирования и анализа данных и процессов;
- наличие совокупности тесно взаимодействующих компонентов (подсистем), имеющих свои локальные задачи и цели функционирования, например, традиционных приложений, связанных с обработкой транзакций и решением регламентных задач, и приложений аналитической обработки (поддержки принятия решений), использующих нерегламентированные запросы к данным большого объема;
- необходимость интеграции существующих и вновь разрабатываемых приложений;
- функционирование в неоднородной среде на нескольких аппаратных платформах;
- разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств.
2.3 Методы и средства проектирования
Структурный метод.
Основным строительным блоком этого метода является процедура или функция, а основное внимание уделяется прежде всего вопросам передачи управления и декомпозиции больших алгоритмов на меньшие. Данный метод является достаточно удобным на этапе анализа и проектирования, потому что работа ведется с бизнес-процессами, по сути являющимися функциями или группами функций. В структурном анализе используются следующие методологии:
- DFD (Data Flow Diagrams) - диаграммы потоков данных;
- IDEFO (Icam DEFinition) - функциональные диаграммы.
Объектно-ориентированный метод.
В качестве основного строительного блока выступает объект или класс. Объект - это сущность, обычно извлекаемая из словаря предметной области или решения, а класс является описанием множества однотипных объектов. Каждый объект обладает идентичностью (его можно поименовать или как-то по-другому отличить от прочих объектов), состоянием (обычно с объектом бывают связаны некоторые данные) и поведением (с ним можно что-то делать или он сам может что-то делать с другими объектами).
2.4 Методологическое обеспечение
Общие сведения
Как известно, на любом предприятии высший приоритет имеют только те проекты, которые непосредственно приносят прибыль, поэтому речь об обследовании деятельности и ее реорганизации обычно идет только во время ощутимого кризиса в управлении компанией. По мере развития конкуренции рентабельность предприятий падает, а руководители сталкиваются с огромными проблемами при попытках оптимизировать затраты, чтобы продукция оставалась одновременно и прибыльной, и конкурентоспособной.
Вот в этот момент и необходимо видеть модель деятельности предприятия, которая отражала бы все механизмы и принципы взаимосвязи различных подсистем в рамках одного бизнеса. С помощью моделирования различных областей деятельности можно достаточно эффективно анализировать «узкие места» в управлении и оптимизировать общую схему бизнеса.
Такая система взаимодействия имеет следующие основные аспекты:
- административный;
- финансовый;
- материальный (товарный);
- информационный;
- коммуникационный.
Взаимодействие на различных уровнях компании не обходится без документооборота, для отображения которого приходится применять универсальные средства, например, диаграммы потоков данных. Но эти диаграммы имеют один существенный недостаток: они показывают перемещение только тех данных (документов), которые доступны для наблюдения (просмотра). В настоящее время на предприятиях наиболее хорошо поддержана формализованным документооборотом финансовая система, административное и материальное взаимодействие, но, как правило, только в части тесно связанной с финансами. Кроме того, на практике встречается множество дополнительных факторов, оказывающих влияние на документооборот, но стандартно не формализуемых.
Методологии IDEF.
Понятие «моделирование бизнес-процессов» стало использоваться аналитиками после появления сложных программных продуктов, предназначенных для комплексной автоматизации управления предприятием. Подобные системы всегда подразумевают проведение глубокого предпроектного обследования деятельности компании или предприятия. Результатом этого обследования является экспертное заключение, в котором отдельными пунктами выносятся рекомендации по устранению «узких мест» в управлении. На основании этого заключения непосредственно перед проектом внедрения системы автоматизации проводится так называемая реорганизация бизнес-процессов, иногда достаточно серьезная и болезненная. Для решения подобных задач моделирования сложных систем существуют хорошо отработанные методологии и стандарты. К таким стандартам относятся методологии семейства IDEF, являющиеся государственным стандартом в США.
IDEF-методологии создавались в рамках предложенной ВВС США программы компьютеризации промышленности, в ходе реализации которой выявилась потребность в разработке методов анализа процессов взаимодействия в производственных (промышленных) системах.
Особенностью рассматриваемого семейства методологий является:
- уникальная способность задавать вопросы в процессе моделирования;
- неразрывная связь графических средств (нотации), методологии и технологии.
Семейство IDEF является системой, которая предоставляет не только средства отображения бизнес-процессов, но и методологию взаимодействия «аналитик-специалист», технологию создания проектов, охватывающую все стадии жизненного цикла - от первичного анализа до формы представления окончательного проекта.
Перечислим наиболее распространенные стандарты семейства IDEF:
- IDEF0.
Методология функционального моделирования, позволяющая с помощью наглядного графического языка предоставить бизнес-систему в виде набора взаимосвязанных функций (функциональных блоков);
- IDEF1.
Методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи;
- IDEF1X (IDEF1 Extended).
Методология построения реляционных структур, которая относится к типу методологий «сущность-взаимосвязь» и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой бизнес-системе;
- IDEF2.
Методология динамического моделирования развития систем. Компьютерные алгоритмы позволяют превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (Color Petri Nets);
- IDEF3.
Методология документирования процессов, позволяющая описывать сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 - каждая функция может быть представлена в виде отдельного процесса средствами IDEF3;
- IDEF4.
Методология построения объектно-ориентированных систем, средства которой позволяют наглядно отображать структуру объектов и заложенные принципы их взаимодействия;
- IDEF5.
Методология онтологического исследования сложных систем, позволяющая описать с помощью определенного словаря терминов и правил состояние бизнес - системы в некоторый момент времени.
2.5 IDEFO
Основные понятия.
Так как на практике наиболее часто используется методология IDEF0, то более подробно остановимся на ее представлении. Эту методологию принято считать последовательницей графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique). IDEFO как стандарт был разработан в 1981 году в рамках программы автоматизации промышленных предприятий ICAM (Integrated Computer Aided Manufacturing) и, как уже упоминалось выше, предлагался для ВВС. С 1981 года IDEFO претерпела несколько незначительных изменений, и последняя его редакция была выпущена в конце 1993 года.
Основу методологии IDEFO составляют четыре основных понятия:
- функциональный блок.
Графически изображается в виде прямоугольника и определяет конкретную функцию для рассматриваемой системы. При этом каждый функциональный блок должен иметь свой уникальный идентификационный номер. Каждая из четырех сторон функционального блока имеет своё определенное значение. Верхняя сторона имеет значение «Управление» (Control), левая сторона - «Вход» (Input), правая сторона - «Выход» (Output) и нижняя сторона - «Механизм» (Mechanism);
- интерфейсная дуга (потоки, стрелки).
С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Такими объектами могут быть элементы реального мира (детали, сотрудники и т.д.) или потоки данных и информации (документы, данные и т.д.). Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование, которое, по требованию стандарта, должно быть оборотом существительного. В зависимости от того, к какой из сторон функционального блока подходит данная интерфейсная дуга, она носит название «входящей», «исходящей» или «управляющей». Кроме того, «источником» (началом) и «приемником» (концом) каждой функциональной дуги могут быть только функциональные блоки, при этом «источником» - может быть только выходная сторона блока, а «приемником» любая из трех оставшихся. Любой функциональный блок по требованиям стандарта должен иметь, по крайней мере, одну управляющую интерфейсную дугу и одну исходящую;
- лекомпозиция.
Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. Декомпозиция позволяет постепенно и структурировано представлять модель системы в виде иерархической структуры отдельных диаграмм. В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint). Цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь, а точка зрения - основное направление развития модели и уровень необходимой детализации. Для того, чтобы не перегружать диаграммы и не делать их сложными для восприятия, в IDEF0 предусмотрено туннелирование, которое обозначается в виде двух круглых скобок вокруг начала интерфейсной дуги. Это указывает на то, что обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из «туннеля») только на этой диаграмме;