Система бизнес-процессов (СБП) является подсистемой системы процессов организации. Основной мотив выделения СБП из всей совокупности процессов организации - уменьшение размеров и уровня сложности объекта управления на этапе управления бизнес-процессами.

Бизнес-процессы существуют в компаниях что при наличии, что при отсутствии управления ими. Компания не может существовать без процессов, происходящих в ней и формирующих ее. Чтобы рассматривать процесс, нужно обратиться к описанию и пониманию его структуры.

Любой процесс, каким бы он ни был, должен строиться из определенных компонентов, которые должны определяться и структурироваться при определении процесса. Типовыми компонентами процесса являются:

входы (сырье, материалы, заготовки, тара, данные и тому подобное)

выходы (результаты функционирования процесса, готовая продукция)

КРОМЕ ТОГО ПРОЦЕСС ВКЛЮЧАЕТ РЕСУРСЫ И ИНФОРМАЦИЮ, НЕОБХОДИМЫЕ ДЛЯ ПОДДЕРЖКИ ПРОЦЕССА, НАПРИМЕР:

используемая технология

персонал (рабочие, служащие, должностные лица и т.п.)

технологическое оборудование (технологические линии, станки, инструменты и т.п.)

метрологическое оборудование

транспортные средства

энергоресурсы

При описании компонентов процесса следует также учитывать наличие инфраструктуры и рабочей среды, необходимых для осуществления процесса. Процессы взаимодействуют, а также являются взаимозависимыми. Перед руководителями встают вопросы по оптимизации и анализу бизнес-процессов.

Международный стандарт ИСО 9000:2000 определяет процесс как совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующих входы и выходы.

Каждый бизнес-процесс: имеет свои границы; имеет конечного потребителя (другого бизнес-процесса или конечного потребителя); имеет своего владельца.

ВОЗМОЖНЫЕ КЛАССИФИКАЦИИ БИЗНЕС-ПРОЦЕССОВ:

Функции (операции) – процессы самого нижнего уровня декомпозиции деятельности организации, как правило, операции выполняются одним человеком.

Все бизнес-процессы организации классифицируются на:

основные, обеспечивающие, развития, управления.

Характерные признаки процессов

1. Назначение процессов – создание основных продуктов. Назначение процессов- обеспечение деятельности основных процессов. Назначение процесса – управление деятельностью всей организации. Назначение процесса - освоение инновационных технологий управления процессами.

2. Результат – основной продукт и/или полуфабрикат для его изготовления. Результат – ресурсы для основных процессов. Результат – деятельность всей организации.

3. Процессы лежат на пути создания основных продуктов. Деятельность процессов не касается основных продуктов.

4. Процессы добавляют к продукту ценность для потребителя. Процессы добавляют продукту стоимость.

3. Принципы построения системы управления бизнес-процессами. Переход от функционального к процессному подходу в управлении предприятием

Управление есть целенаправленное информационное воздействие на людей и экономические объекты, осуществляемое с целью направить их действия и получить желаемые результаты.

Следует различать управление предприятием с использованием бизнес-процессов и управление собственно процессами.

Что означает управлять БП?

ü Строго соблюдать регламент процесса;

ü В случае отклонения, уметь вырабатывать корректирующее воздействие, возвращающее процесс в рамки регламента

Любое управление, в том числе управление бизнес-процессами, должно быть построено на основе следующих принципов:

1. Принцип точного ритма (ритмичности), сущность которого заключается в обеспечении выхода определенных объемов продукции за равные периоды времени и соответственно точное повторение бизнес-процесса на всех стадиях.

2. Принцип единых стандартов (стандартизации). Введение единых стандартов и требований как к приобретаемым товарам у контрагентов, так и к выпускаемым продуктам своего производства позволяет избежать не только необоснованного многообразия в материалах, но и часто происходящей «несовместимости» материалов и оборудования, систем и программных продуктов.

3. Принцип потока (прямоточности). Суть данного принципа лежит в бесперебойной подаче комплектующих материалов, полуфабрикатов и прочих сборочных единиц по всем стадиями и операциям, начиная с запуска производственной линии до выхода готовых продуктов.

4. Принцип автоматизации. Автоматизация - одно из направлений научно-технического прогресса, включающее в себя применение саморегулирующих технических средств, экономико-математических методов и систем управления, освобождающих человека от участия в процессах получения, преобразования, передачи и использования энергии, материалов или информации, существенно снижающих трудоёмкость выполняемых данных операций.

5. Принцип оптимальности (сопоставления результатов и затрат), заключается в том, что оценка эффективности внедрения того или иного бизнес-процесса должна осуществляться путем сопоставления эффекта и затратами на его внедрение.

6. Принцип вариантности, заключается в том, что при принятии тех или иных решений, связанных с внедрением бизнес-процесса, следует рассматривать различные способы достижения поставленной цели.

7. Принцип сопоставимости альтернатив. При выборе оптимальных решений при проектировании бизнес-процессов очень часто приходится сталкиваться с несопоставимостью имеющихся альтернатив, так как данные процессы могут протекать в разных производственных условиях, существуют госзаказы и т. д.

8. Принцип учета неопределенности, позволяет снизить уровень риска принятия решений при внедрении того или иного бизнес-процесса.

СУБП - это целенаправленная система с обратной связью, объектом управления которой является СБП, а в качестве процесса управления выступает совокупность взаимосвязанных действий владельца СБП, обеспечивающая такое изменение параметров объекта управления, которое необходимо для достижения целей организации.

Если частично пожертвовать строгостью, можно дать более короткое определение:

СУБП - система управления, в рамках которой владелец СБП обеспечивает функционирование и совершенствование СБП для достижения целей организации.

В настоящее время существует два основных подхода к управлению бизнес-процессами: функциональный и процессный.

Функция (лат. functio - исполнение) - обязанность, круг деятельности, подлежащая исполнению работа - служебные функции.

Функция, это работа, которую обязан выполнить субъект, что бы достигнуть поставленной цели.

Функция, это круг обязанностей субъекта в рамках:

§ данного процесса;

§ нескольких процессов;

§ структурного подразделения;

§ всей организации в целом.

Проце́сс (от лат. processus - продвижение), - последовательная смена состояний объекта во времени.

Природа объекта может быть произвольной: материальный (природный или искусственный) или идеальный (понятие, теория и т.п.) объект порождает соответственно материальный или идеальный процесс.

Таким образом, функция – это задача, которую решает компания для собственного выживания и для достижения поставленных целей. Функция отвечает на вопрос что делать. Разумеется, в рамках компании можно выделить множество функций. Так любая бизнес-система должна обладать такими функциями, как управление финансами, производство, продажи.

Бизнес-процесс, в свою очередь, – это реализация функции во времени, способ решения бизнес-задачи. Бизнес-процесс описывает то, как функция выполняется, в какой последовательности и в каких вариантах, а также то, как функции взаимодействуют между собой в работе компании. Бизнес-процесс отвечает на вопрос как делать.

В свете этих соображений, спор о том, внедрять ли процессное управление или нет, лучше ли оно функционального или как, напоминает спор двух схоластов о том, есть ли глаза у крота. Когда же садовник предложил ученым мужам поймать крота и посмотреть ему в глаза, ученые решительно отказались от подобных услуг – они спорили, есть ли глаза у крота в принципе, а не у крота в огороде. Одним словом, выделение и противопоставление функционального и процессного подходов представляется едва ли конструктивным для управленческой практики.

Аннотация: Принципы создания информационной системы. Реинжиниринг бизнес-процессов. Отображение и моделирование процессов. Обеспечение процесса анализа и проектирования ИС возможностями CASE-технологий. Внедрение информационных систем.

4. Разработка и внедрение информационной системы

4.1. Принципы создания информационной системы

Многие пользователи компьютерной техники и программного обеспечения неоднократно сталкивались с ситуацией, когда программное обеспечение, хорошо работающее на одном компьютере, не работает на другом таком же устройстве. Или системные блоки одного вычислительного устройства не стыкуются с аппаратной частью другого. Или информационная система другой компании упорно не желает обрабатывать данные, которые вы подготовили в информационной системе у себя на рабочем месте. Эта проблема называется проблемой совместимости вычислительных, телекоммуникационных и информационных устройств.

Развитие систем и средств вычислительной техники, расширенное их внедрение во все сферы науки, техники, сферы обслуживания и быта привели к необходимости объединения конкретных вычислительных устройств и реализованных на их основе информационных систем в единые информационно-вычислительные системы (ИВС) и среды. При этом разработчики ИВС столкнулись с рядом проблем.

Например, разнородность технических средств вычислительной техники с точки зрения организации вычислительного процесса, архитектуры, системы команд, разрядности процессора и шины данных и т. д. потребовала создания физических интерфейсов, реализующих, как правило, взаимную совместимость устройств. При увеличении числа типов интегрируемых устройств сложность организации физического интерфейса между ними существенно возрастала. Разнородность программируемых сред, реализуемых в конкретных вычислительных устройствах и системах, с точки зрения многообразия операционных систем, различия в разрядности и прочих особенностей привела к созданию программных интерфейсов между устройствами и системами. При этом необходимо отметить, что достигнуть полной совместимости программных продуктов, разработанных для конкретной программной среды, в другой среде удавалось не всегда. Разнородность интерфейсов общения в системе "человек-компьютер" требовала постоянного согласования программно-аппаратного обеспечения и пер еобучения кадров.

Принцип "открытости" информационной системы

Решение проблем совместимости привело к разработке большого числа международных стандартов и соглашений в сфере применения информационных технологий и разработки информационных систем. Основополагающим понятием стало понятие открытые системы.

Термин "открытая система" сегодня можно определить как "исчерпывающий и согласованный набор международных стандартов на информационные технологии и профили функциональных стандартов, которые специфицируют интерфейсы, службы и поддерживающие их форматы, чтобы обеспечить взаимодействие и мобильность программных приложений, данных и персонала".

Это определение, сформулированное специалистами института IEEE (Institute of Electrical and Electronic Engineers), унифицирует содержание среды, которую предоставляет открытая система для широкого использования. В настоящее время общепризнанным координационным центром по разработке и согласованию стандартов открытых систем является OASIS (Organization for the Advancement of Structured Information Standards).

Общие свойства открытых информационных систем можно сформулировать следующим образом:

• расширяемость/масштабируемость: обеспечение возможности добавления новых функций ИС или изменения некоторых уже имеющихся при неизменных остальных функциональных частях ИС;
• мобильность/переносимость: обеспечение возможности переноса программ, данных при модернизации или замене аппаратных платформ ИС и возможности работы с ними специалистов, пользующихся ИТ, без их переподготовки при изменениях ИС;
• взаимодействие: способность к взаимодействию с другими ИС (технические средства, на которых реализована информационная система, объединяются сетью или сетями различного уровня: от локальной до глобальной);
• стандартизуемость: ИС проектируются и разрабатываются на основе согласованных международных стандартов и предложений, реализация открытости осуществляется на базе функциональных стандартов (профилей) в области информационных технологий;
• дружественность к пользователю: развитые унифицированные интерфейсы в процессах взаимодействия в системе "человек-машина", позволяющие работать пользователю, не имеющему специальной "компьютерной" подготовки.

Новый взгляд на открытые системы определяется тем, что эти черты рассматриваются в совокупности, как взаимосвязанные, и реализуются в комплексе, что вполне естественно, поскольку все указанные выше свойства дополняют друг друга. Только в совокупности возможности открытых систем позволяют решать проблемы проектирования, разработки и внедрения современных информационных систем.

Структура среды информационной системы

Обобщенная структура любой ИС может быть представлена двумя взаимодействующими частями:

• функциональной части, включающей прикладные программы, которые реализуют функции прикладной области;
• среды или системной части, обеспечивающей исполнение прикладных программ.

С этим разделением тесно связаны две группы вопросов стандартизации:

• стандарты интерфейсов взаимодействия прикладных программ со средой ИС, прикладной программный интерфейс (Application Program Interface - API);
• стандарты интерфейсов взаимодействия самой ИС с внешней для нее средой (External Environment Interface - EEI).

Эти две группы интерфейсов определяют спецификации внешнего описания среды ИС - архитектуру, с точки зрения конечного пользователя, проектировщика ИС, прикладного программиста, разрабатывающего функциональные части ИС.

Спецификации внешних интерфейсов среды ИС и, как будет видно далее, спецификации интерфейсов взаимодействия между компонентами самой среды, - это точные описания всех необходимых функций, служб и форматов определенного интерфейса. Совокупность таких описаний составляет эталонную модель открытых систем (Reference Open System Model).

Эта модель используется более 20 лет и определяется системной сетевой архитектурой (SNA), предложенной IBM в 1974 году. Она основана на разбиении вычислительной среды на семь уровней, взаимодействие между которыми описывается соответствующими стандартами, и обеспечивает связь уровней вне зависимости от построения уровня в каждой конкретной реализации (рис. 4.1). Основным достоинством этой модели является детальное описание связей в среде с точки зрения технических устройств и коммуникационных взаимодействий. Вместе с тем она не принимает в расчет взаимосвязь с учетом мобильности прикладного программного обеспечения.

Рис. 4.1.

Эталонная модель среды открытых систем (OSE/RM) определяет разделение любой информационной системы на приложения (прикладные программы и программные комплексы) и среду, в которой эти приложения функционируют. Между приложениями и средой определяются стандартизованные интерфейсы (API), которые являются необходимой частью профилей любой открытой системы. Кроме того, в профилях ИС могут быть определены унифицированные интерфейсы взаимодействия функциональных частей друг с другом и интерфейсы взаимодействия между компонентами среды ИС.

Более подробно о применении технологии и моделей открытых систем будет рассказано в "лекции 18" .

Модель создания информационной системы

Методологически важно наряду с рассмотренными моделями среды ИС предложить модель создания ИС, которая имела бы те же аспекты функциональных групп компонентов (пользователи, функции, данные, коммуникации). Такой подход обеспечит сквозной процесс проектирования и сопровождения на всех стадиях эксплуатации ИС и возможность обоснованного выбора стандартов на разработку систем и документирование проектов.

Компания является сложной онтологической (понятийной) структурой, состоящий из определенной совокупности сущностей и взаимосвязей (рис. 4.2).

Рис. 4.2.

Взаимодействия между её элементами, определяемые бизнес-логикой и закрепленные в наборе бизнес-правил, и является деятельностью компании. Информационная система "отражает" логику и правила, организуя и преобразуя информационные потоки, автоматизирует процессы работы с данными и информацией и визуализирует результаты в виде наборов отчетных форм. Поэтому для начала следует создать бизнес-модель предприятия, которая является отображением предприятия и его информационно-управляющей системы.

При создании модели формируется "язык общения" руководителей предприятия, консультантов, разработчиков и будущих пользователей, позволяющий выработать единое представление о том, ЧТО и КАК должна делать система управления предприятием (корпоративная система управления). Такая бизнес-модель - осязаемый результат, с помощью которого можно максимально конкретизировать цели внедрения ИС и определиться со следующими параметрами проекта:

• основные цели бизнеса, которые можно достичь посредством автоматизации процессов;
• перечень участков и последовательность внедрения модулей ИС;
• фактическая потребность в объемах закупаемого программного и аппаратного обеспечения;
• реальные оценки сроков развертывания и запуска ИСУ;
• ключевых пользователей ИС и уточненный список членов команды внедрения;
• степень соответствия выбранного вами прикладного программного обеспечения специфике бизнеса вашей компании.

В основе модели всегда лежат бизнес-цели предприятия, полностью определяющие состав всех базовых компонентов модели:

• бизнес-функции, описывающие ЧТО делает бизнес;
• основные, вспомогательные и управленческие процессы, описывающие КАК предприятие выполняет свои бизнес-функции;
• организационно-функциональную структуру, определяющую ГДЕ исполняются бизнес-функции и бизнес-процессы;
• фазы, определяющие КОГДА (в какой последовательности) должны быть внедрены те или иные бизнес-функции;
• роли, определяющие КТО исполняет бизнес-функции и КТО является "хозяином" бизнес-процессов;
• правила, определяющие связь и взаимодействие между всеми ЧТО, КАК, ГДЕ, КОГДА и КТО.

После построения бизнес-модели (или параллельно с этим) можно приступать к формированию модели проектирования, реализации и внедрения самой ИС (рис. 4.3).

Рис. 4.3.

Опыт создания и использования "заказных" ИС позволяет условно выделить следующие основные этапы их жизненного цикла:

• определение требований к системе и их анализ - определение того, что должна делать система;
• проектирование - определение того, как система будет делать то, что она должна делать; проектирование это, прежде всего, спецификация подсистем, функциональных компонентов и способов их взаимодействия в системе;
• разработка - создание функциональных компонентов и отдельных подсистем, соединение подсистем в единое целое;
• тестирование - проверка функционального соответствия системы показателям, определенным на этапе анализа;
• внедрение - установка и ввод системы в действие;
• функционирование - штатный процесс эксплуатации в соответствии с основными целями и задачами ИС;
• сопровождение - обеспечение штатного процесса эксплуатации системы на предприятии заказчика.

Определение требований к системе и анализ является первым этапом создания ИС, на котором требования заказчика уточняются, согласуются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: "Для чего предназначена и что должна делать информационная система?". Именно здесь лежит ключ к успеху всего проекта.

Целью системного анализа является преобразование общих, расплывчатых знаний об исходной предметной области (требований заказчика) в точные определения и спецификации для разработчиков, а также генерация функционального описания системы. На этом этапе определяются и специфицируются:

• внешние и внутренние условия работы системы;
• функциональная структура системы;
• распределение функций между человеком и системой, интерфейсы;
• требования к техническим, информационным и программным компонентам системы,
• требования к качеству и безопасности;
• состав технической и пользовательской документации;
• условия внедрения и эксплуатации.

Разработка перечисленных выше спецификаций при создании ИС, предназначенной для автоматизации управленческих процессов, в общем случае проходит четыре стадии.

Первая стадия анализа - структурный анализ предприятия - начинается с исследования того, как организована система управления предприятием, с обследования функциональной и информационной структуры системы управления, определения существующих и возможных потребителей информации.

По результатам обследования аналитик на первой стадии строит обобщенную логическую модель исходной предметной области, отображающую ее функциональную структуру, особенности основной деятельности и информационное пространство, в котором эта деятельность осуществляется (рис. 4.4). На этом материале аналитик строит функциональную модель "Как есть" (As Is).

Вторая стадия работы, к которой обязательно привлекаются заинтересованные представители заказчика, а при необходимости и независимые эксперты, состоит в анализе модели "Как есть", выявлении ее недостатков и узких мест, определение путей совершенствования системы управления на основе выделенных критериев качества.

Третья стадия анализа, содержащая элементы проектирования, - создание усовершенствованной обобщенной логической модели, отображающей реорганизованную предметную область или ее часть, которая подлежит автоматизации - модель "Как должно быть" (As To Be).

Заканчивается процесс (четвертая стадия) разработкой "Карты автоматизации", представляющей собой модель реорганизованной предметной области, на которой обязательно обозначены "границы автоматизации".

В большинстве случаев модель "Как есть" улучшается системным аналитиком за счет устранения очевидных несоответствий и узких мест, а полученный таким образом вариант модели рассматривается в дальнейшем в качестве предварительной модели "Как должно быть", которая впоследствии дополняется в соответствии со стратегией развития предприятия (рис.4.5).

Рис. 4.5.

На стадии анализа требований к проектируемой системе и вводятся:

• классы пользователей и соответствующие диаграммы бизнес-транзакций;
• модели (диаграммы) процессов прикладной деятельности и соответствующие перечни функциональных задач ИС;
• классы объектов предметной области и соответствующие диаграммы "сущность-связь", отражающие информационную модель этой предметной области;
• топология расположения подразделений и пользователей, обслуживаемых данной ИС;
• параметры защиты данных, информации и самой системы.

Основным документом, отражающим результаты работ первого этапа создания ИС, является техническое задание на проект (разработку), содержащее, кроме вышеперечисленных определений и спецификаций, также сведения об очередности создания системы, сведения о выделяемых ресурсах, директивных сроках проведения отдельных этапов работы, организационных процедурах и мероприятиях по приемке этапов, защите проектной информации и т. д.

Следующий этап - проектирование. В реальных условиях проектирование - это поиск, моделирование способа разработки, который удовлетворяет требованиям функциональности системы средствами имеющихся технологий с учетом заданных начальных условий и ограничений. Проектирование информационных систем всегда начинается с определения цели проекта. Основная задача любого успешного проекта заключается в том, чтобы на момент запуска системы и в течение всего времени ее эксплуатации можно было обеспечить:

• требуемую функциональность системы и степень адаптации к изменяющимся условиям ее функционирования;
• требуемую пропускную способность системы и минимальное время реакции системы на запрос;
• безотказную работу системы в требуемом режиме, готовность и доступность системы для обработки запросов пользователей;
• простоту эксплуатации и сопровождения системы;
• необходимую безопасность данных и права доступа пользователей.

Производительность и надёжность являются главными факторами, определяющими эффективность системы. Хорошее проектное решение служит основой высокопроизводительной системы.

Проектирование информационных систем охватывает три основные области:

• проектирование структур данных, которые будут реализованы в базе данных;
• проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
• проектирование конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры, параллельной обработки, распределенной обработки данных и т. п.

На основе результатов системного анализа на стадии предварительного проекта разрабатываются:

• проект программно-аппаратной реализации, проект пользовательских интерфейсов и технологии работы пользователей в системе;
• архитектура распределенной системы и спецификации телекоммуникационной сети;
• модели (диаграммы) потоков данных;
• функциональные блок-схемы прикладного и системного программного обеспечения (последние - в соответствии с принятыми моделями среды ИС и профилями стандартов).

Стадия предварительного проекта может предусматривать прототипирование фрагментов, важных с точки зрения пользователя для проверки их соответствия требованиям на ранней фазе разработки.

На стадии детального проектирования разрабатываются:

• комплексы функциональных программ ИС и проект реализации среды ИС;
• структуры данных, средства ведения баз данных;
• сетевые адреса, протоколы телекоммуникаций и другие компоненты среды обмена информацией, включаемые в состав проектируемой ИС;
• правила разграничения доступа пользователей и средства их реализации.

Стадия реализации ИС предусматривает разработку и тестирование компонентов и комплексное тестирование системы.

Стадия эксплуатации и сопровождения предусматривает контроль функционирования ИС, внесение требуемых изменений в информационную базу в процессе текущей работы и модернизацию функций ИС силами прикладных специалистов с помощью инструментальных средств, встроенных в систему.

Этапы разработки, тестирования, внедрения, эксплуатации и сопровождения ИС объединяются термином - реализация. Реализация ИС является чрезвычайно сложным многоаспектным процессом, осуществляемым на базе совокупностей (профилей) гармонизированных международных стандартов, спецификаций и соглашений. Такая практика является залогом того, что создаваемая информационная система будет реализована как "открытая система". Иными словами такая ИС будет масштабируема, мобильна, переносима, обладать дружественными интерфейсами и т. д.

Жизненный цикл ИС формируется в соответствии с принципом нисходящего проектирования и, как правило, носит спирально-итерационный характер. Реализованные этапы, начиная с самых ранних, циклически повторяются в соответствии с изменениями требований и внешних условий, введением дополнительных ограничений и т. п. На каждом этапе жизненного цикла порождается определенный набор технических решений и документов, при этом для каждого этапа исходными являются документы и решения, принятые на предыдущем этапе. Жизненный цикл ИС заканчивается, когда прекращается её программное и техническое сопровождение.

4.2. Реинжиниринг бизнес-процессов

Внедрение информационных технологий и реализованных на их основе информационных систем в повседневную деятельность предприятия дает ему тактические и долгосрочные преимущества в бизнесе. Стремление руководства к использованию ИТ может остаться лишь благими намерениями, если оно не будет следовать сложившимся требованиям и правилам разработки, проектирования и внедрения ИТ. Выше говорилось о базовых требованиях к стандартизации объектов и функциональных задач, без которых реализуемая система не будет являться открытой системой, что приведет впоследствии к многочисленным проблемам при ее внедрении и эксплуатации.

Следование требованиям стандартов при разработке ИС автоматически приводит к тому, чтобы само предприятие - внешняя среда для ИС - также отвечало необходимым требованиям: определение и стандартизация классов пользователей и объектов, топология потоков данных и работ, архитектура наследуемых и разрабатываемых подсистем, состояние бизнес-процессов и т. д.

Бизнес-процесс представляет собой систему последовательных, целенаправленных и регламентированных видов деятельности, в которой посредством управляющего воздействия и с помощью определенных ресурсов за определенное время входы процесса преобразуются в выходы - в результаты, представляющие ценность для потребителя и приносящие прибыль изготовителю.

Стандартный бизнес-процесс в масштабах предприятия реализуется в виде сети основных, вспомогательных, поддерживающих и управленческих процессов (рис. 4.6).

Рис. 4.6.

При этом разделение на основные и вспомогательные процессы в определяющей степени зависит от предметной области и направления деятельности предприятия: для производственной компании, например, деятельность юридического отдела является вспомогательной, а для юридической или консалтинговой фирмы - основной. Идентификация процессов является обязательным условием, без реализации которого невозможна информатизация деятельности.

Руководители предприятия, решившиеся на внедрение ИТ, должны твердо усвоить - начало работ по проектированию информационной системы чаще всего влечет за собой обязательный реинжиниринг бизнес-процессов! Реинжиниринг представляет собой множество методик и рекомендаций, среди них нужно выбрать те, которые наилучшим образом удовлетворяют поставленным целям.

Реинжиниринг бизнес-процессов - это совокупность методов и действий, служащих для перепроектирования процессов в соответствии с изменившимися условиями внешней и внутренней среды и/или целями бизнеса.

Существует несколько базовых правил, которых следует придерживаться в процессе проведения реинжиниринга:

• разработка последовательных пошаговых процедур для перепроектирования процессов;
• использование в проектировании стандартных языков и нотаций;
• наличие эвристических и прагматических показателей, позволяющих оценить или измерить степень соответствия перепроектированного процесса или функциональности заданным целям;
• подход к решению частных задач и к их совокупности должен быть системным;
• даже небольшое улучшение должно давать быстрый положительный эффект.

Реинжиниринг деловых процессов и функций начинается с пересмотра целей предприятия, его структуры, анализа потребностей внутренних пользователей и рынка, производимых продуктов и услуг (рис. 4.7).

Рис. 4.7.

Перепланирование целей и задач предполагает пересмотр политики предприятия и ответа на следующие вопросы:

• Какие новые вызовы предъявляют нам изменившиеся условия бизнеса?
• Что представляет предприятие сейчас, и что мы хотим от него в будущем?
• Каких именно потребителей мы обслуживаем, насколько мы удовлетворяем их требования и ожидания, и что нужно сделать для привлечения новых?
• Какие именно показатели определяют эффективность деятельности предприятия, производительность труда и качество продукта, является ли это определение полным и адекватным?
• Какие именно информационные технологии и средства помогут нам в этом?

Для ответа на эти ключевые вопросы необходимо в первую очередь провести детальное описание бизнес-архитектуры предприятия, его бизнес-логики, построить функциональную модель взаимодействия бизнес-процессов, ресурсов и персонала и отразить её в архитектуре ИС, содержании модулей информационных подсистем и визуализации форм представления информации. Необходимо также иметь методики и инструменты реорганизации процессов, решения прикладных задач и управления проектом реинжиниринга (рис. 4.8). Описание бизнес-архитектуры предприятия позволяет:

Рис. 4.8.

• построить схему основных потоков данных, работ, движения финансов и документов;
• понять, как информация распределяется между подразделениями, и кто является конечным пользователем в том или ином бизнес-процессе;
• описать взаимодействие процессов и модулей информационной системы;
• определить критическую важность видов информации для конкретных уровней управления предприятием;
• выявить дублированные структуры и связи.

Результатом такого описания является:

• уточненная карта сети процессов;
• матрица взаимосвязей процессов и подразделений, вовлеченных в эти процессы;
• информация о том, какие системы автоматизации существуют, при выполнении каких операций используются, где и какие данные используются, какие системы автоматизации и информатизации необходимо разработать;
• функциональные схемы потоков данных (Data Flow), работ (Work Flow), финансовых потоков (Cash Flow), потоков управленческих воздействий (Control Flow) и документооборота (Doc Flow).

Функциональная модель поможет составить точные спецификации всех операций, процедур и взаимосвязей между ними. Такая модель, если она построена правильно, обеспечивает исчерпывающее описание о функционирующем процессе и обо всех имеющихся в нем потоках информации. Эта модель описывает состояние "Как есть" (As Is). По результатам анализа возможных путей улучшения от реальной модели нужно перейти к модели, характеризующей улучшения - модель "Как будет" (As To Be), вариант - "Как должно быть" (рис. 4.9).

Рис. 4.9.

Функциональное моделирование является достаточно серьезной проблемой, полнота и соответствие построенной модели зависят как от средств моделирования, так и от квалификации специалистов, выполняющих это моделирование.

Реинжиниринг бизнес-процессов является сложным и многоаспектным проектом, требующим тщательного планирования и проработки деталей. В таблице 4.1 показаны основные этапы реинжиниринга.

Таблица 4.1. Основные этапы реинжиниринга

Этап	Мероприятия
Планирование и начало работ	Выявление главных причин проведения реформы на предприятии и оценка последствий отказа от такой реформы
	Выявление важнейших процессов, требующих реинжиниринга
	Выявление единомышленников среди руководства и создание рабочей группы из представителей администрации
	Обеспечение поддержки проекта руководством
	Подготовка плана проекта: определение объема, обозначение измеримых целей, выбор методологии, составление подробного графика
	Согласование целей и объемов проекта с руководством
	Формирование группы реинжиниринга
	Выбор консультантов или внешних экспертов
	Проведение вводного совещания
	Доведение целей проекта до руководителей низшего звена; начальное информирование всей организации
	Обучение группы реинжиниринга
	Подготовка плана и начало работ
Исследования	Аналитическое исследование опыта компаний с подобными процессами
	Опрос клиентов и контрольных групп для выявления существующих и будущих требований
	Опрос служащих и руководителей для выявления вопросов; мозговой штурм
	Поиск в литературе и прессе данных о тенденциях в отрасли и о чужом опыте
	Оформление подробных документов на исходные процессы и сбор рабочих данных; выявление недоработок
	Обзор изменений и вариантов технологий
	Опрос владельцев и представителей руководства
	Посещение кружков и семинаров
	Сбор данных от внешних экспертов и консультантов
Проектирование	Мозговой штурм и выработка новаторских идей; упражнения по творческому мышлению, чтобы "снять шоры"
	Проработка сценариев "а что, если?" и применение "шаблонов успеха" других компаний
	Создание при помощи специалистов 3-5 моделей; разработка комплексных моделей, в которых собрано лучшее от каждой из предыдущих
	Создание картины идеального процесса
	Определение моделей нового процесса и их графическое представление
	Разработка организационной модели в сочетании с новым процессом
	Определение технологических требований; выбор платформы для новых процессов
	Выделение краткосрочных и долгосрочных мер
Утверждение	Анализ затрат и преимуществ; расчет прибыли на капитал
	Оценка влияния на клиентов и служащих; оценка влияния на конкурентоспособность
	Подготовка официального документа для высшего руководства
	Проведение обзорных совещаний для ознакомления и утверждения деталей проекта оргкомитетом и высшим руководством
Внедрение	Завершение подробной разработки процессов и организационных моделей; определение новых рабочих обязанностей
	Разработка систем поддержки
	Реализация предварительных вариантов и первичные испытания
	Ознакомление работников с новым вариантом; разработка и осуществление плана реформы
	Разработка поэтапного плана; внедрение как таковое
	Разработка плана обучения; обучение работников новым процессам и системам
Последующие мероприятия	Разработка мероприятий по периодической оценке; определение итогов нового процесса; внедрение программы непрерывного совершенствования нового процесса
	Предоставление окончательного отчета оргкомитету и администрации

4.3. Отображение и моделирование процессов

На сегодняшний день получили распространение три основные методологии функционального моделирования (и сопутствующий им инструментарий): IDEF (Integrated DEFinition), UML (Unified Modeling Language) и ARIS (Architecture of Integrated Information Systems). Для каждой из них существуют определенные программные продукты, которые помимо разработки позволяют проводить преобразования и операции для последующей работы с полученными моделями. Наибольшее распространение сегодня получили методологии IDEF и программный продукт BPWin, содержащий методологии IDEF0, IDEF3, DFD (Data Flow Diagrams) и ERWin (IDEF1x) от компании Computer Associates.

История методологии IDEF начинается с 70-х годов ХХ века с методологии SADT (Structured Analysis and Design Technique), разработанной Дугласом Россом (Softtech INC). Изначально SADT применялось Министерством Обороны США для практического моделирования процессов в рамках программы ICAM (Integrated Computer Aided Manufacturing). Принципиальным требованием при разработке рассматриваемого семейства методологий была возможность эффективного обмена информацией между всеми специалистами - участниками программы ICAM (Icam DEFinition). В последующем эта методология была трансформирована в стандарт IDEF0 (Function Modeling, FIPS № 183). Семейство IDEF включает уже упомянутые IDEF3 (Process Description Capture) и IDEF1x (Data Modeling, FIPS № 184).

После опубликования стандартов они были успешно применены в самых различных областях бизнеса, показав себя эффективным средством анализа, конструирования и отображения бизнес-процессов (к слову сказать, он активно применяется и в отечественных госструктурах, например в Государственной налоговой инспекции). Более того, собственно с широким применением IDEF (и предшествующей методологии SADT) и связано возникновение основных идей популярного ныне понятия "реинжиниринг бизнес-процессов" (Business Process Reengineering - BPR).

Информационный процесс - это устойчивый процесс (последовательность работ и действий с данными и информацией), относящийся к сопровождению производственно-хозяйственной деятельности компании и обычно ориентированный на информационное обслуживание создания новой стоимости. Бизнес-процесс включает в себя иерархию взаимосвязанных функциональных действий, реализующих одну (или несколько) бизнес-целей компании и отражающий результаты в информационной системе, например, информационное обеспечение управления и анализа выпуска продукции или ресурсное обеспечение выпуска продукции (под продукцией здесь понимают товары, услуги, решения, документы).

Работа с использованием метода IDEF начинается с постановки цели моделирования. Мировой опыт свидетельствует, что ошибки при постановке цели приводят в среднем к 50 % неудач в процессе моделирования. Формулирование цели изначально направляет работу в заданном направлении, а значит, ограничивает круг вопросов для анализа. Практическая работа начинается с определения контекста (Context, Context Diagram), то есть верхнего уровня системы, в нашем случае - предприятия. После формулировки цели необходимо очертить область моделирования (Scope), которая в последующем будет определять общие направления движения и глубину детализации (Decomposition). Собственно, сама методология IDEF определяет стандартизированные объекты для работы и отображения. Например, к таковым относятся функция (Activity), интерфейсная дуга (Arrow), заметка (Note) а также способ их расположения и трактования (Semantics).

В последнее время на российском рынке появился программный продукт Business Studio, который специально создан для работы с методами IDEF и обладает интуитивным и дружественным интерфейсом (User-friendly Interface).

Рис. 4.10.

В основе нотации и методологии IDEF0 лежит понятие "блока", то есть прямоугольника, который выражает некоторую функцию бизнеса (рис. 4.10). В соответствии со стандартом функция должна быть выражена глагольным оборотом В IDEF0 роли сторон прямоугольника (функциональные значения) различны: верхняя сторона имеет значение "управление", левая - "вход", правая - "выход", нижняя - "механизм исполнения".

Вторым элементом методологии и нотации является "поток", называемый в стандарте "интерфейсная дуга". Это элемент, описывающий данные, неформальное управление, или что-либо другое, оказывающее влияние на функцию, изображенную блоком. Потоки обозначаются оборотом существительного.

В зависимости от того, к какой стороне блока направлен поток, он, соответственно, носит название "входной", "выходной", "управляющий". Изобразительным элементом, представляющим поток, является стрелка. Поток можно интерпретировать как представление объекта, под которым понимается как информационный объект, так и реальный физический объект.

Важным фактором является то, что "источником" и "приемником" потоков (то есть, началом и концом стрелки) могут быть, как правило, только блоки. При этом источником может являться только выходная сторона блока, приемником - любая из трех оставшихся. Если же необходимо подчеркнуть внешний характер потока, то может быть применен метод "туннелирования" - скрытие или появление интерфейсной дуги из "туннеля".

И, наконец, "третьим китом" методологии IDEF0 является принцип функциональной декомпозиции блоков, который представляет собой модельную интерпретацию той практической ситуации, что любое действие (тем более такое сложное, как бизнес-процесс) может быть разбито (декомпозировано) на более простые операции (действия, бизнес-функции). Или, другими словами, действие может быть представлено как совокупность элементарных функций.

Пример функциональной модели процесса отгрузки и доставки продукции показан на рис. 4.11 .

Степень формализации описания бизнес-процессов может быть различной в зависимости от решаемых при этом задач. Для описания информационных процессов разработан специализированный язык BPEL (Business Process Execution Language). BPEL создан на основе XML для формального описания бизнес-процессов и протоколов их взаимодействия между собой. BPEL расширяет модель взаимодействия Web-служб и включает в эту модель поддержку транзакций.

В настоящее время активно развивается методология BPMS (Business Process Management System) - класс программного обеспечения для управления бизнес-процессами и административными регламентами. (Употребляются также термины BPM-система и просто BPM). Использование BPMS позволяет организовать эффективное взаимодействие между управленцами и ИТ-специалистами, лучше использовать существующие подсистемы и ускорить разработку новых.

Основные функции BPMS - моделирование, исполнение и мониторинг бизнес-процессов. Основываясь на данных мониторинга, предприятия выявляют узкие места и усовершенствуют свои бизнес-процессы. Цикл управления замыкается, когда при помощи BPMS измененные бизнес-процессы оперативно внедряются в эксплуатацию.

Современные методы разработки и развития программного обеспечения ИС в полной мере стараются ориентироваться на возможности автоматизированного оперативного внесения изменений. Наиболее сложным оказался процесс стандартизации языка BPEL для унификации использования одних и тех же конструкций программным обеспечением разных производителей. Фирмы IBM и Microsoft определили два довольно-таки схожих языка: WSFL (Web Services Flow Language) и Xlang, соответственно.

Рост популярности BPML и открытое движение BPMS к пользователям привело корпорации Intalio Inc., IBM и Microsoft к решению объединить эти языки в новый язык BPEL4WS. В апреле 2003 года корпорации BEA Systems, IBM, Microsoft, SAP и Siebel Systems передали BPEL4WS версии 1.1 в OASIS для стандартизирования в Web Services BPEL Technical Committee. Хотя BPEL4WS появился в версиях 1.0 и 1.1, технический комитет WS-BPEL OASIS проголосовал 14 сентября 2004 за то, чтобы назвать спецификацию WS-BPEL 2.0. Это изменение было сделано, чтобы согласовать BPEL с другими стандартами Web-сервисов, которые на основании "Соглашения об именовании" начинаются сочетаниями букв "WS-".

Корпорации Active Endpoints, Adobe, BEA, IBM, Oracle и SAP опубликовали согласованные спецификации BPEL4 People и WS-HumanTask, в которых описывалось, как может быть реализовано в системе и нотациях BPEL взаимодействие процессов с людьми. Предполагается добавление в BPEL семантики в форме WS-HumanTask и других разнообразных дополнений.

4.4. Обеспечение процесса анализа и проектирования ИС возможностями CASE-технологий

Термин CASE (Computer Aided Software/System Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом.

Теперь под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного программного обеспечения (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. Таким образом, современные CASE-средства вместе с системным программным обеспечением и техническими средствами поддержки образуют полную среду разработки ИС.

Появлению CASE-технологии и CASE-средств предшествовали исследования в области методологии программирования. Программирование обрело черты системного подхода с разработкой и внедрением языков высокого уровня, методов структурного и модульного программирования, средств визуального моделирования и проектирования на базе языка UML (Unified Modeling Language), средств их поддержки, формальных и неформальных языков описаний системных требований и спецификаций и т. д. Кроме того, появлению CASE-технологии способствовали и такие факторы, как:

• подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования;
• широкое внедрение и постоянный рост производительности компьютеров, позволившие использовать эффективные графические средства и автоматизировать большинство этапов проектирования;
• внедрение сетевой технологии, предоставившей возможность объединения усилий отдельных исполнителей в единый процесс проектирования путем использования разделяемой базы данных, содержащей необходимую информацию о проекте.

CASE-технология представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методологиях структурного (в основном) или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств [Вендров А. М. ,www.citforum. ru/database/case/index.shtml ].

CASE-средства позволяют создавать не только продукт, практически готовый к использованию, но и обеспечить "правильный" процесс его разработки. Основная цель технологии - отделить проектирование программного обеспечения от его кодирования, сборки, тестирования и максимально "скрыть" от будущих пользователей все детали разработки и функционирования ПО. При этом значительно повышается эффективность работы проектировщика: сокращается время разработки, уменьшается число программных ошибок, программные модули можно использовать при следующих разработках.

Большинство CASE-средств основано на парадигме "методология/метод/нотация/структура/средство".

Методология задает руководящие указания для оценки и выбора проекта разработки ПО, этапы и последовательность работ, правила применения тех или иных методов.

Метод - систематическая процедура или технология генерации описаний компонент ПО (например, описание потоков и структур данных).

Нотации предназначены для описания системы в целом, ее элементов: графы, диаграммы, таблица, блок схемы, алгоритмы, формальные языки и языки программирования.

Структуры являются средством для реализации структурного анализа и построения структуры конкретной системы.

Средства - технологические и программные инструменты для поддержки и усиления методов.

CASE-технологии обладают следующими основными достоинствами, которые позволяют широко использовать их при разработке информационных систем:

• ускоряют процесс коллективного проектирования и разработки;
• позволяют за короткий срок создать прототип заказанной системы с заданными свойствами;
• освобождают разработчика от рутинной работы, оставляя время для творчества;
• обеспечивают эффективность и качество разрабатываемого ПО за счет автоматизации контроля всего процесса разработки;
• поддерживают сопровождение и развитие системы на высоком уровне.

Следует отметить, что, несмотря на все потенциальные возможности CASE-средств, существует достаточно много примеров их неудачного внедрения, в результате которых CASE-средства становятся "полочным" ПО (Shelfware).

В связи с этим необходимо учитывать следующее:

• CASE-средства не обязательно дают немедленный эффект, он может быть получен только спустя какое-то время;
• реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;
• CASE-средства обеспечивают возможности для получения существенной выгоды только после успешного завершения процесса их внедрения, эффективного обучения пользователей и регулярного применения.

Можно также перечислить следующие факторы, усложняющие определение возможного эффекта от использования CASE-средств:

• широкое разнообразие качества и возможностей CASE-средств;
• относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения;
• широкое разнообразие в практике внедрения различных организаций;
• отсутствие детальных метрик и данных для уже выполненных и текущих проектов;
• широкий диапазон предметных областей проектов;
• различная степень интеграции CASE-средств в различных проектах.

Некоторые аналитики считают, что реальная выгода от использования некоторых типов CASE-средств может быть получена только после одно- или двухлетнего опыта. Другие полагают, что воздействие может реально проявиться в фазе эксплуатации жизненного цикла ИС, когда технологические улучшения могут привести к снижению эксплуатационных затрат.

Ниже перечислены основные виды и последовательность работ, рекомендуемые при построении логических моделей предметной области в рамках CASE-технологии анализа системы управления предприятием.

1. Проведение функционального и информационного обследования системы управления (административно-управленческой деятельности) предприятия (рис. 4.2):
   • определение организационно-штатной структуры предприятия;
   • определение функциональной структуры предприятия;
   • определение перечня целевых функций структурных элементов (подразделений и должностных лиц);
   • определение круга и очередности обследования структурных элементов системы управления согласно сформулированным целевым функциям;
   • обследование деятельности выделенных структурных элементов;
   • построение FD-диаграммы системы управления с указанием структурных элементов и функций, реализация которых будет моделироваться на DFD-уровне.
2. Разработка моделей деятельности структурных элементов и системы управления в целом:
   • выделение множества внешних объектов, оказывающих существенное влияние на деятельность структурного элемента;
   • спецификация входных и выходных информационных потоков;
   • выявление основных процессов, определяющих деятельность структурного элемента и обеспечивающих реализацию его целевых функций;
   • спецификация информационных потоков между основными процессами деятельности, уточнение связей между процессами и внешними объектами;
   • оценка объемов, интенсивности и других необходимых характеристик информационных потоков;
   • разработка иерархии диаграмм потоков данных, образующих функциональную модель деятельности структурного элемента;
   • объединение DFD-моделей структурных элементов в единую модель системы управления предприятием.
3. Разработка информационных моделей структурных элементов и модели информационного пространства системы управления:
   • определение сущностей модели и их атрибутов;
   • проведение атрибутного анализа и оптимизация сущностей;
   • идентификация отношений между сущностями и определение типов отношений;
   • анализ и оптимизация информационной модели;
   • объединение информационных моделей в единую модель информационного пространства.
4. Разработка предложений по автоматизации системы управления предприятия:
   • определение границ автоматизации - составление перечня автоматизируемых структурных элементов, разбиение процессов основной деятельности на автоматические, автоматизированные и ручные;
   • составление перечня подсистем и логических АРМов (автоматизированных рабочих мест), определение способов их взаимодействия;
   • разработка предложений по очередности проектирования и реализации подсистем и отдельных логических АРМов, входящих в состав ИС;
   • разработка требований к средствам базового технического обеспечения ИС;
   • разработка требований к средствам базового программного обеспечения ИС.

Логическая модель, отображающая деятельность системы управления предприятия и информационное пространство, в котором эта деятельность протекает, представляют собой "снимок" положения дел (функциональная структура, роли должностных лиц, взаимодействие подразделений, принятые технологии обработки управленческой информации, автоматизированные и неавтоматизированные процессы и т. д.) на момент обследования. Эта модель позволяет понять, что делает и как функционирует предприятие с позиций системного анализа, сформулировать предложения по улучшению ситуации.

Развитие логической модели предметной области, ее последовательное превращение в модель целевой ИС, позволит интегрировать перспективные предложения руководства и ведущих сотрудников предприятия, экспертов и системных аналитиков, сформировать видение новой, реорганизованной и автоматизированной деятельности предприятия (рис. 4.12).

Рис. 4.12.

Построенная модель является законченным результатом по следующим причинам.

1. Она включает в себя модель существующей неавтоматизированной технологии, принятой на предприятии. Формальный анализ этой модели позволяет выявить узкие места в управлении предприятием и сформулировать рекомендации по его улучшению (независимо от того, предполагается ли дальнейшая разработка автоматизированной системы или нет).
2. Она независима и отделяема от конкретных разработчиков, не требует сопровождения и может быть безболезненно передана другим лицам. Более того, если по каким-либо причинам предприятие не готово к реализации проекта в данный момент времени, модель может быть "положена на полку" до тех пор, пока в ней не возникнет необходимость.
3. Она позволяет осуществлять эффективное обучение новых работников конкретным направлениям деятельности предприятия, так как соответствующие технологии содержатся в модели.
4. С ее помощью можно осуществлять предварительное моделирование перспективных направлений деятельности предприятия с целью выявления новых потоков данных, взаимодействующих процессов и структурных элементов.
5. Она обеспечивает распространение накопленного опыта на других предприятиях, дает возможность унифицировать административно-управленческую и финансовую деятельность этих предприятий.

Модель является не просто реализацией начальных этапов работы и основанием для формирования технического задания на ее последующие этапы. Она представляет собой самостоятельный результат, имеющий большое практическое значение, так как позволяет дальнейшее применение CASE-технологий для реального проектирования и разработки ИС.

Paradigm Plus - моделирование приложений и генерация объектного кода;

Rational Rose - моделирование бизнес-процессов и компонентов приложений

Rational Suite AnalystStudio - пакет для аналитиков данных;

Oracle Designer (входит в Oracle9i Developer Suite) - высоко функциональное средство проектирования программных систем и баз данных, реализующее технологию CASE и собственную методологию Oracle - CDM. Позволяет команде разработчиков полностью провести проект, начиная от анализа бизнес-процессов через моделирование к генерации кода и получению прототипа, а в дальнейшем и окончательного продукта. Сложное CASE-средство, имеет смысл использовать при ориентации на линейку продуктов Oracle.

Самым мощным из указанных программных пакетов является пакет Rational Rose (RR) компании IBM-Rational, с помощью которого можно спроектировать и сопровождать весь жизненный цикл разработки программного продукта (рис. 4.15 Рис. 4.16. Сопровождение ЖЦ программного продукта с RR

4.5. Внедрение информационных систем

Внедрение корпоративной ИС, разработанной самостоятельно или приобретенной у поставщика, зачастую сопровождается ломкой (перепроектированием) существующих на предприятии бизнес-процессов. Приходиться перестраивать их под требования стандартов и логику внедряемой системы. Отметим сразу, что внедрение ИС решает ряд управленческих и технических проблем, однако порождает проблемы, связанные с человеческим фактором.

Внедрение информационной системы, как правило, значительно облегчает управление деятельностью предприятия, оптимизирует внутренние и внешние потоки информации, ликвидирует узкие места в управлении. Однако после того как система успешно установлена, "обкатана" в работе и показала свою эффективность, у части сотрудников выявляется нежелание использовать ИС в работе. В результате проведённого реинжиниринга становится ясно, что некоторые сотрудники в большой степени дублирует работу других или вовсе не нужна. Кроме того, внедрение КИС сопровождается обязательным обучением, но, как показывает российский опыт, желающих переучиваться не так много. Ломка старых навыков и прививание новых - долгий и трудный процесс!

Надо четко понимать, что корпоративная ИС призвана упростить управление организацией, улучшить процессы, усилить контроль и обеспечить этим конкурентные выгоды. Только с такой точки зрения можно оценивать пользу от её внедрения.

Следуя этой логике, становится понятно, что хотя корпоративная ИС предназначена в целом для обеспечения всех пользователей необходимой информацией, управление разработкой и внедрением КИС является прерогативой высшего руководства компании! Понимают ли это руководители?

Здесь тоже приходиться бороться с живучими стереотипами. "Зачем мне корпоративная система, если дела на предприятии и так идут хорошо?". "Зачем, что-то ломать, если все работает?". Но ведь ломать-то чаще всего и не надо. На первом этапе нужно лишь грамотно и корректно формализовать и перенести идентифицированные процессы, в рамках которых живет предприятие, в корпоративную ИС. Подобная формализация лишь отточит, отшлифует удачные маркетинговые и производственные находки, оптимизирует процесс управления и контроля и позволит в дальнейшем проводить целенаправленные изменения.

Внедрение новой ИС - сложный процесс, длящийся от нескольких месяцев для небольших ИС до нескольких лет для ИС больших распределенных компаний с широкой номенклатурой продуктов и большим количеством поставщиков. Успех проекта по разработке (приобретению) и внедрению ИС во многом зависит от готовности предприятия к ведению проекта, личной заинтересованности и воли руководства, реальной программы действий, наличия ресурсов, обученного персонала, способности к преодолению сопротивления на всех уровнях сложившейся организации.

К настоящему времени сложился стандартный набор приемов внедрения ИС. Основное правило: выполнять обязательные фазы последовательно и не пропускать ни одной из них.

Критически важными для внедрения являются следующие факторы:

• наличие четко сформулированных целей проекта и требований к ИС;
• наличие стратегии внедрения и использования ИС;
• проведение предпроектного обследования предприятия и построения моделей "Как есть" и "Как будет";
• планирование работ, ресурсов и контроль выполнения плана внедрения;
• участие высшего руководства во внедрении системы;
• проведение работ по внедрению ИС специалистами по интегрированию систем совместно со специалистами предприятия;
• регулярный мониторинг качества выполняемых работ;
• быстрое получение положительных результатов хотя бы в части внедренных модулей ИС или в процессе её опытной эксплуатации.

Перед началом разработки проекта внедрения необходимо:

• максимально формализовать цели проекта внедрения ИС;
• оценить минимально необходимые затраты и статьи расхода;
• установить высокий приоритет проекта внедрения перед остальными текущими проектами;
• наделить руководителя проекта максимально возможными полномочиями;
• провести массовую просветительскую работу с персоналом предприятия с целью довести до каждого важность и необходимость предстоящих преобразований;
• разработать организационные меры для применения новых информационных технологий;
• распределить персональную ответственность по всем этапам внедрения и опытной эксплуатации.

Необходимо также определить функциональные сферы внедрения модулей информационной системы:

• организационное управление;
• организационно-административное обеспечение;
• управление бизнес-процессами;
• управленческий, планово-финансовый и бухгалтерский учет;
• управление персоналом;
• управление документацией;
• управление материально-техническим обеспечением;
• управление связями с клиентами и внешней средой.

Кроме того, что перечислено выше, надо задать технологические требования к внедрению ИС:

• системная платформа: внедрение и адаптация готового решения от производителя или разработка на заказ в соответствии с техническим заданием заказчика.
• интегрируемость: данные хранятся и обрабатываются в едином информационном пространстве - это обеспечивает их полноту, непротиворечивость, достоверность и возможность многократного использования; система может включать в себя вновь разработанные и уже используемые технологии и приложения.
• адаптируемость: система настраивается в соответствии с требованиями заказчика и на особенности информационного поля заказчика.
• распределенность: система может эффективно функционировать в территориально удаленных подразделениях и филиалах предприятия.
• масштабируемость: система может выполняться в виде каркаса, содержащего базовые модули, и дополняться в соответствии с требованиями изменяющейся внешней и внутренне среды.

Основные фазы внедрения информационной системы

Фаза "Предварительные работы по подготовке проекта внедрения ИС". В ходе предпроектного обследования предприятия (рис. 4.1.4) собирается подробная информация о структурном построении организации, функциональных связях, системе управления, об основных бизнес-процессах, о потоках внутри предприятия (Control Flow, Doc Flow, Data Flow, Work Flow, Cash Flow), необходимая для построения соответствующих моделей и выбора объектов для автоматизации. Оцениваются сроки, ресурсы, виды и объемы работ, номенклатура и стоимость программно-аппаратных и телекоммуникационных средств, стоимость обучения персонала и т. д.

Фаза "Подготовка проекта". После завершения первой фазы осуществляется предварительное планирование и формирование процедур запуска проекта:

• формирование проектной и экспертной групп;
• распределение полномочий и ответственности;
• определение организационно-технических требований к процессу внедрения;
• уточнение спецификаций и ожиданий заказчика;
• обучение группы внедрения, состоящей из специалистов предприятия-заказчика.

Последний очень важный момент почему-то часто пропускается при составлении плана внедрения. А ведь от него в огромной степени зависит успех всего проекта! После начала финансирования проект считается запущенным к исполнению.

Фаза "Концептуальная проработка проекта". В течение этой фазы:

• формируется и утверждается концептуальный проект;
• достигается обязательное однозначное понимание намерений всех участников проекта относительно внедряемой ИС;
• уточняются и конкретизируются цели и задачи проекта;
• определяются размеры прототипа системы;
• согласуются укрупненный план работы, последовательность этапов и условия опытной эксплуатации, планово-финансовые и отчетные показатели.

При этом все указанные действия в обязательном порядке документируются, согласуются и утверждаются всеми заинтересованными и ответственными сторонами.

Фаза "Реализация проекта". Во время проведения основных работ по внедрению создается, устанавливается и конфигурируется системная среда, определяются процедуры системного администрирования, устанавливаются основные программно-аппаратные комплексы и приложения. В системе настраиваются организационно-штатные и организационно-функциональные структуры предприятия с использованием таких организационных единиц, как филиал, департамент, отдел, рабочая группа и т. д.

Отрабатываются системные вопросы безопасности работы системы в многопользовательском режиме. Создаются приложения, шаблоны, отчеты, клиентские формы доступа, распределятся полномочия пользователей. Проводится "прогонка" всех систем в "боевом режиме" с участием всех заинтересованных сторон. После окончания фазы реализации проект внедрения считается законченным. Информационная система передается в эксплуатацию.

Мифы управления бизнес процессами не дают мне покоя. Практически каждый день, мне их рассказывают в разных комбинациях и интерпретациях. Иногда, я пытаюсь объяснить их ошибочную природу. Иногда лишь молча улыбаюсь. Но чаще всего, мне приходится разгребать последствия, ведь вера в мифы, порождает реальность.

Я собрал наиболее распространенные мифы по вопросам управления бизнес процессами и разбил на 4 категории:
1. Мифы управления бизнес процессами
2. Мифы применения управления бизнес процессами
3. Мифы внедрения процессного подхода
4. Не дайте себя обмануть
Разрушайте мифы, которые могут привести к реальным последствиям.

Мифы управления бизнес процессами

Создание моделей и есть управления бизнес процессами

Наверное один из самых распространенных мифов, который прочно прижился в российских компаниях. Многие действительно полагают, что суть управления бизнес процессами заключается в создании моделей, однако это далеко от истины. Давайте разберемся почему.

Управление бизнес процессами отвечает за следующие виды деятельности в компании:
– Анализ бизнес процессов
– Проектирование процессов
– Моделирование процессов
– Описание бизнес процессов
– Изменение и трансформация бизнес процессов
– Внедрение
– Мониторинг и контроль
– Увеличение эффективности
– А иногда, еще и за организацию

Составляющие управления бизнес процессами

Как видите, моделирование процессов является лишь небольшой частью, а , отвечает за эффективность и постоянное улучшение деятельности компании. Просто через призму бизнес процессов. Собственно это не удивительно и не является преувеличением, потому что изначально, концепция управления бизнес процессами создавалась именно для организации постоянно улучшения деятельности компаний. Если хотите, то единственной целью управления бизнес процессами, является непрерывное увеличение конкурентоспособности компании. Но вернемся к моделированию.

Таким образом – модель, это инструмент, который облегчает управление бизнес процессами. И все.

Именно поэтому во многих компаниях, специалисты по управлению по бизнес процессам, занимаются только моделирование и описанием.

Тут правда существует еще один миф, связанный с тем, что подготовить модель может практически каждый сотрудник. Это не просто миф, но очень вредоносное мнение.
Процесс моделирования, в умелых руках, превращается сразу в анализ и проектирование. Это позволяет сэкономить много времени при планировании дальнейших улучшений, ведь в процессе моделирования, специалист уже исправляет и предусматривает дальнейшие улучшения.

Для того, чтобы модель эффективно выполняла свои функции, она обязательно должна быть простой и однозначно понятной. А чтобы готовить такие модели, скажу я вам, нужны обширные , опыт и особый определенный склад ума.

Моделирование является небольшой, но довольно сложной, частью управления бизнес процессами. Задача моделирования – получить инструмент для последующего анализа, проектирования и контроля бизнес процессов.

Суть управления бизнес процессами это написание регламентов и других документов

Создание моделей бизнес процессов, это для продвинутых. Тот, кто легких путей не ищет, ценит олдскул и предпочитает хардкор, считает, что для того, чтобы управлять бизнес процессами, необходимо завалить сотрудников регламентами и прочей документацией. Помните пример о 70и страничном описании процедуры из предыдущего пункта? Вот это как раз об этом. Думаю нет смысла расписывать масштаб проблем, порожденных убеждением в текущем мифе.

Ряд представителей фанатично убеждены, что большой объем документации является показателем реального управления бизнес процессами. Что, собственно, управление бизнес процессами должно только этим и заниматься – развивать бумажную промышленность. Причем именно бумажную, потому что электронная документация не приемлема. Она же не позволяет завалить рабочий стол и создать видимость работы)))

В одной компании мне довелось увидеть такое количество документации, регламентирующей действия сотрудников, что при пересчете «на душу населения» получилось около 2000 печатных страниц на каждого сотрудника. Т.е. Каждый человек в компании, должен в своей работе учитывать и следовать внутренним правилам, описанным на 2000 страницах. И это только внутренние документы. Здесь не учитываются требования законодательства и контролирующих органов.
В общем, миф опасный и вредный. Он формирует неправильное представление об управлении бизнес процессами, позволяет понапрасну тратить ресурсы компании, создает препятствия в управлении и т.д.

На самом деле, тут как и с моделями бизнес процессов – документ это инструмент. Инструмент, который связывает то, как что-то задумано, с тем, как оно работает на самом деле. Вот только не надо рассказывать о том, что документы не работают! Конечно, сами по себе они не будут работать, тут надо еще усилия приложить. Но как инструмент – все именно так.
С точки зрения управления бизнес процессами, документом является любая информация, имеющая физическое воплощение. Это означает, что к такой информации можно обратиться, прочитать, изучить, иногда прикрыться от дождика и т.д.

Документация помогает доносить и использовать информацию, но никак не является сутью управления бизнес процессами.

Цель управления бизнес процессами – сделать из людей роботов в жесткой системе

Многие представители технических профессий именно так и считают. Нужно максимально регламентировать деятельность сотрудников. Так, чтобы они не могли сделать ни шага в сторону. А так как в России, функции процессного управления часто перекладываются именно на техническое направление, миф о «роботизации» сотрудников прочно укоренился в корпоративной среде. Как следствие, компании и направления, связанные в той или иной степени с «творческой» составляющей работы, панически бегут от процессного управления.

Как и многие мифы об управлении бизнес процессами, этот вреден и, даже, жесток. Нет ничего более глупого, чем стараться сделать из людей роботов и не пользоваться преимуществами человеческой составляющей.
Скорее всего, те, кто пропагандирует данный подход, являются сторонниками теории Х МакГрегора. Но не суть.

Развеять этот миф очень просто с помощью 4х аргументов:

1. Во всех бизнес процессах, кроме полностью автоматизированных, участвуют люди. Если не учитывать особенности, связанные с ними, то изменения, а управление бизнес процессами всегда связано с изменениями, не будут успешными. Все профессионалы по управлению бизнес процессами и изменениями, однозначно согласны с тем, что при планировании и реализации управления, необходимо учитывать:
   – Культуру организации
   – Негласные правила
   – Поведенческие особенности
   – Идеи и замыслы
   – Коммуникации и правила, принятые в компании
2. Управление бизнес процессами ориентируется на процессов, а не на их стандартизацию. Кто сказал, что увеличение эффективности возможно только с помощью стандартизации? Ах да, Генри Форд. Хороший был дядька. Сделал целую промышленную революцию. Но стандартизация изделий не идентична стандартизации процессов. Далеко не всегда, стандартизация, как единственно верный способ выполнения процесса, будет полезен. Необходимо выполнять процессы таким образом, чтобы они были эффективны, а не стандартны.
3. Правильно спроектированный и внедренный процесс, предусматривает множество сценариев развития и возможность создания нового! Без потери заданной эффективности. Это высший пилотаж управления бизнес процессами. Вероятно стоит посвятить данному вопросу отдельную статью.
4. Использование уровней управления, принципов и правил, позволяет обеспечить эффективность при весьма большой свободе действий. Нет необходимости пытаться описать процесс написания картины художником. Однако процесс создания картины описать можно. Более того, это может повысить эффективность процесса написания, за счет устранения отвлекающих факторов – например подготовки мольберта, красок и т.д.

Поймали мысль?

Создание человеческих роботов, не является целью управления бизнес процессами. Цель – обеспечить эффективность и развитие процессов. А использование творческой и человеческой составляющих, скорее усиливает, чем вредит процессу.

Автоматизация операций это управление бизнес процессами

Давайте договоримся сразу – автоматизация и управление, это совершенно разные вещи. Управление бизнес процессами, это о, ээээ, ну, управлении. А не автоматизации. И ключевое слово здесь – бизнес. Т.е. это управление, направленное на достижение бизнес целей.
Миф о том, что управление бизнес процессами и есть автоматизация, в корне не верен. Он появился тогда, когда «не технари» не проявили достаточно системных подходов в управлении и вопросы системности отдали на откуп тем, кому они ближе – «технарям». А они, в свою очередь, родили шикарную легенду о тотальной автоматизации, как единственном инструменте повышения эффективности и управления. Время и принцип испорченного телефона, привели к тому, что смысл автоматизации, как вспомогательного инструмента для бизнеса, был забыт, а внедрение ИТ технологий стало самодостаточным.

На самом деле, автоматизация, это инструмент. Один из инструментов управления и повышения эффективности. Один из многих инструментов.

Тема управления бизнес процессами становится все более популярной. На рынке появилось огромное количество сервисов и приложений, не требующих глубоких технических знаний, для использования и настройки. На этом фоне стало появляться большое количество «специалистов», предлагающих услуги по «автоматизации бизнес процессов».
Большинство из них говорит о CRM, автоматизации маркетинговых процессов, автоматизации продаж и так далее. Все они говорят о том, что занимаются оптимизацией и настройкой бизнес процессов.

Иногда можно даже встретить такие сообщения:

«Кстати, мы тут бота запили. Диагностику бизнеса проводит и аудит сайта…»

Занавес. Недоуменное молчание. Кто то нервно идет в курилку, а кто то в буфет.

Эти «специалисты» упускают из вида две вещи:
1. То, что они делают, очень далеко от автоматизации бизнес процессов, их настройки и, тем более, от управления бизнес процессами. Максимум, что они делают, это автоматизируют операции и некоторые процедуры. Например они могут наладить запись клиентских заявок с сайта в вашу систему CRM. Это как то очень далеко от оптимизации бизнес процессов, вы не находите?

2. Оптимизация бизнес процессов невозможна без твердого фундамента, в виде стратегии, методологии и оценки бизнес процессов на многих уровнях. Да и взаимосвязи процессов на уровне организации не стоит забывать. В противном случае, можно получить, к примеру, огромный поток клиентских обращений, на который нужно будет тратить ресурсы, а конверсия и рентабельность продаж, будут только уменьшаться.

Оптимизация бизнес процессов и автоматизация процедур, это разные вещи. Автоматизация процедур это частичка не только в управлении бизнес процессами, но и в нормальной автоматизации.

Мифы применения управления бизнес процессами

В нашей компании / отрасли управление бизнес процессами не сработает

Сработает. Вот именно в вашей отрасли и в вашей организации – обязательно сработает.
В мире нет такой отрасли, в которой еще не были бы применены принципы управления бизнес процессами. От аэрокосмической промышленности, до оказания эскорт услуг. Креативные агентства, туристические фирмы, логистические операторы, представители тяжелой и леееегонькой промышленности, ИТ компании и даже казино! Этот список можно продолжать бесконечно.

Управление бизнес процессами работает в любой отрасли, и вот почему:

1. Универсальность принципов. Базовые принципы управления одинаково применяются во всех организациях. Специальные принципы тоже применяются повсеместно, но, как правило, видоизменяются под действием особенностей компании. В управлении бизнес процессами, тоже существуют принципы, которые применимы для любой компании. Вне зависимости сферы деятельности, вы будете определять границы бизнес процессов исходя из одних и тех же принципов. Не важно что вы производите – элементы космически спутников, или создаете интернет страницы, вы будете одинаково определять промежуточные продукты процессов. Принципы работают везде.
2. Адаптивность подходов. Существует множество подходов к управлению бизнес процессами. Прелесть в том, что опираясь на принципы управления бизнес процессами, вы будете адаптировать подходы, под свои конкретные нужды. Более того, правильное внедрение и использование подходов, будет заключать в себе механизмы адаптации. Каждый, правильно спроектированный процесс, заключает в себе такой механизм.
3. Комбинации методологий. Многие методологии оптимизации бизнес процессов, хорошими по себе. Но управление, предполагает поиск и внедрение такой комбинации методов, которая позволит показать наибольшую эффективность в конкретных условиях. Эта комбинация будет работать наилучшим образом только для вас. Кстати именно поэтому, слепое копирование подходов и методов других компаний не сработает в вашей компании.
4. Простота реализации. Для того чтобы получить преимущества управления бизнес процессами, не нужно высокоточных приборов и передовых информационных технологий. Да, технологии помогают, но это не главное. Управление бизнес процессами очень просто в реализации т.к. интуитивно понятным людям. Процессный подход основывается на логике и взаимосвязанности. А для их использования не нужны дорогостоящие инструменты.

Процессный подход всегда основывается на действительности вашей компании.

Мы пробовали управлять процессами – это не работает

И действительно. Много компаний пытались освоить управление процессами и потерпели фиаско. Вот несколько примеров того, что делали такие компании:
– Создали многотомные описания процессов и процедур, и решили, что дальше люди сами будут по ним работать.
– Назначили владельцев бизнес процессов, но не объяснили зачем то нужно и как совмещать роль функционального и процессного руководителя.
– Внедрили супер продвинутую систему электронного документооборота, но не перевели работу сотрудников в нее. В результате затраты не только не упали, но и существенно выросли.
Все это реальные примеры, реальных компаний.

Для них это не сработало. Почему? Потому что реализация.
Реализация хромает. У нас ведь это часто бывает – идея вроде хороша, но исполнение все губит.
А губит потому, что недооценили и не продумали. Не вникли в суть. Ведь дело, как я уже говорил выше, не в описании процессов, а в том, что вы делаете с этим дальше.

Когда человек говорит, что он пробовал пробежать марафон, но у него не получилось и «вообще это не мое», стоит выяснить – а что было для этого сделано и сколько он пробежал. А то часто получается, что пробежал он от булочной до подъезда 500 метров, устал, запыхался и решил бросить эту затею. Но он ведь пытался. Целых 500 метров пробежал. Из 42 километров. Понимаете мою мысль?

Прежде чем говорить, что что-то не работает, убедитесь в том, что все сделано правильно. За инструкцию надо браться до использования, а не после того, как все сломалось.

Использование управления бизнес процессами очень сложно и работает только в крупных компаниях

Ну да, ну да. А бег доступен только профессиональным атлетам.
Если у вас две ноги и две руки (и то необязательно), то вы можете бегать.

Если вы уже занимаетесь управлением, вы можете использовать управление бизнес процессами.

Миф о доступности передовых технологий управления, только крупным компаниям, связан с мнением о необходимости использования дорогостоящего оборудования, программного обеспечения и штата специалистов. Мол, это все дорого и только крупные компании, могут позволить себе тратить такие ресурсы.

Надеюсь я вас обрадую – все это не так.
Не нужно супер оборудование, программное обеспечение класса ERP и специалисты мирового уровня.
Все что необходимо – это освоить методологию и подумать как реализовать ее имеющимися ресурсами.
Дорогое ПО, можно заменить доступными аналогами. Специалисты есть не только дорогие и раскрученные, но и очень даже доступные и человечные. А все оборудование может быть заменено на ноутбук, блокнот, ручку и телефон. Хотите узнать как? Спросите)))

В моей практике, я видел компании, совершенно не использующие преимущества современных технологий, но являющимися лидерами в своих отраслях. Встречались и обратные примеры, когда персонал «межзвездного корабля» не знал как со всем этим работать и только тратил впустую ресурсы компании.

Для управления бизнес процессами нужна только ваша компания и ваши процессы. Всем дорогим ресурсам можно найти доступный аналог.

Нет смысла заниматься процессами в небольших компаниях

Самая малочисленная компания, с которой я имел дело, не насчитывала и пяти человек.

Если вы занимаетесь обслуживанием клиентов по телефону, не важно сколько человек в компании выполняет эту работу. Это может быть один человек и десять тысяч. При этом процессы будут не сильно различаться.
Да, на той стадии, пока компания маленькая и весь персонал располагается в одном гараже, вопросы управления не встают остро. Но вопросы эффективности актуальны вне зависимости от размера.

Даже ваши личные процессы можно оптимизировать и эффективно управлять.

Более того, если компания не очень большая, она как правило очень стеснена в ресурсах, поэтому вопрос максимально эффективного их использования – это вопрос выживания.

Начинайте заниматься управлением бизнес процессами даже на стадии стартапа из одного человека. Это принесет намного больше выгоды, чем все возможные финансовые инвестиции.

Нельзя управлять “творческими процессами”

Творческими процессами управлять можно и нужно, но несколько иначе.
Я не говорю о том, что нужно управлять, например, самими процессом написания новеллы. Когда даже сам писатель не в состоянии объяснить как такой процесс происходит. Но необходимо сконцентрироваться на вспомогательных процессах, т.е. Тех процессах, которые создадут наилучше условия для выполнения основного.

Что я имею ввиду? Ну например для того, чтобы призвать писательскую музу и создать действительно достойное произведение, вам может потребоваться наличие определенной музыки и освещения. Возможно вам будет помогать чашка свежезаваренного кофе на столе и так далее.
В таком случае необходимо сосредоточиться на том, чтобы выполнять процессы, связанные с получением необходимых условий, максимально эффективно.

Как вы думаете, используется ли процессный подход в таких компаниях, как Google ? Конечно используется. Вы же наверняка слышали о том, что в офисах этой корпорации сотрудники могут отлично питаться, спать, отдыхать, играть в игры, заниматься спортом и так далее. Вы думаете это сделано просто потому, что они большие и имеют много денег. Нет!
Это исключительно прагматичный ход, основанный на вышеупомянутых принципах управления бизнес процессами – люди избавлены от необходимости беспокоится и выполнять вспомогательные процессы, для того чтобы могли сосредоточиться на основных.
Вот так работает управление бизнес процессами.

Управление творческими процессами осуществляется через вспомогательные.

И кстати, если вас интересует прямое управление творческими процессами, обратитесь к трудам Эдварда де Боно. Он предлагает ряд крайне интересных механизмов.

Мифы применения процессного подхода

Чтобы заниматься управлением бизнес процессами, нужно разбираться в тонкостях работы

Этот миф касается не только управления бизнес процессами, но управления в принципе. Почему то многие считают, что для того, чтобы управлять, необходимо детально знать особенности самых мелких операций.
В результате встречаются ситуации, когда хорошие специалисты в своем деле, выдвинутые на управленческие позиции, принимают решения, приносящие вред компании. В России это встречается особенно часто. В прошлом году, на ярмарке венчурных инвестиций, представитель одного крупного зарубежного фонда сказал – «Беда многих компаний в том, что великолепные ученые и инженеры, пытаются взять на себя бразды правления компанией, понятия не имея о навыках управления». И это действительно так.

Управленческие навыки и специальные, это совершенно разные вещи. Управленцу не нужно разбираться в тонких аспектах выполнения специальных операций. Он должен уметь организовать работу специалистов таким образом, чтобы они максимально эффективно выполняли задачи, приводящие к целям компании.

Если вы обратите внимание на такую дисциплину как менеджмент, то сразу заметите разделение управления и выполнения. Эффективность этого разделения доказана уже давно.

Управление происходит на разных уровнях и только на операционном уровне необходимы специальные знания, для того, чтобы оценить, к примеру, эффективность применения или реализации технологии.

Чем выше уровень управления, тем меньше специальных знаний требуется. И наоборот. Чем ближе управленце к выполнению операций, тем больше он должен обладать специальными знаниями.

Управление бизнес процессами также проходит на разных уровнях, однако до того, как появится необходимость углубиться в технологии и операции, нужно выполнить много работы на других уровнях. И за это время, управленец успеет разобраться в особенностях операционной деятельности настолько, насколько необходимо для эффективного управления.

Хороший управленец, всегда будет управлять эффективнее самого высококлассного специалиста.

Управление бизнес процессами, в первую очередь занимается управлением, а принципы управления универсальны и не требуют узких знаний операционной работы. Приобретение специальных знаний происходит быстрее, чем получение управленческих навыков.

Мы справимся своими силами

На мой взгляд, я привел уже достаточно аргументов, развенчивающих мифы о сложности управления бизнес процессами. Однако было бы ошибочным полагать, что все настолько элементарно, чтобы можно было быстренькое внедрить изменения у себя в компании.

Собственно в этом и скрывается подвох. Сама методология управления бизнес процессами, действительно очень проста. Но она напрямую связана с изменениями, а изменениями нужно управлять таким образом, чтобы они работали. В этом и заключается основная сложность для не специалистов в области управления процессами и изменениями. Мы сейчас говорим об узко специальных навыках из предыдущей части. Только яти навыки касаются не производственных технологий, а технологий управления изменениями.

Специалисты могут оценить с какими сложностями столкнется компания в процессе изменений и заранее позаботиться об их устранении. Это вопрос специальных навыков, знаний и опыта. Привлечение специалистов обходится гораздо дешевле устранения последствий изменений своими силами.

Второй момент, связанный с мифом – довольно часто, время сотрудников, выделяемое на внедрение управления бизнес процессами, планируется по остаточному принципу. Т.е. сотрудники уделяют функциональными задачам основную часть времени и, если останется, делают что то, связанное с изменениями.
Этот подход категорически не работает. Если вы хотите, чтобы изменения были реализованы, это должно стать ежедневной обязанностью всех заинтересованных сотрудников. Со всеми вытекающими воздействия на них.

Опять же, чаще всего, сотрудники просто игнорируют работу по изменениям по причине высокой загрузки. Здесь ведь нужно не только делать работу, но и прикладывать серьезные умственные усилия. А высокая текучка к этому не располагает.

Это еще одна причина, почему привлечение стороннего специалиста будет крайне полезно, а порой просто необходимо.

Чтобы быть уверенным в своих силах, нужно выделить ресурсы на внедрение изменений. Привлечение специалистов по управлению бизнес процессами и изменениями – важный, а порой необходимый, шаг.

У нас не хватит ресурсов на внедрение

Для того чтобы оценить хватит у вас ресурсов или нет, нужно понимать, какие ресурсы нужны и в каком количестве.

Основным ресурсом, который вам понадобится, является время сотрудников. При этом на начальной стадии, больше всего времени уходит у высшего руководства. Чем дальше продвигается проект по уровням управления, тем меньше требуется время топов. Для примера, я бы привел следующие цифры:

Стадия определения границ бизнес процессов
– Топ менеджмент – 4-5 часа в неделю.
– Средний менеджмент – 5-6 часов в неделю.
– Функциональные руководители – 2-3 часов в неделю.
– Специалисты – 1-2 часа в неделю.

Стадия описания бизнес процессов


– Функциональные руководители – 4-5 часов в неделю.
– Специалисты – 6-8 часов в неделю.

Стадия планирования изменений
– Топ менеджмент – 4-5 часов в неделю.
– Средний менеджмент – 7-8 часов в неделю.
– Функциональные руководители – 7-8 часов в неделю.
– Специалисты – 4-5 часов в неделю.

Стадия внедрения изменений
– Топ менеджмент – 1 час в неделю.
– Средний менеджмент – 2-3 часов в неделю.
– Функциональные руководители – 8-12 часов в неделю.
– Специалисты – 8-10 часа в неделю.

В общем, на внедрение изменений необходимо выделять 20 – 30% рабочего времени задействованных сотрудников. Помните – изменения не внедряются одновременно, но волнообразно, так что фактически, вы выделяете совсем немного времени, относительно всех ресурсов компании.

Это конечно очень примерная и грубая оценка, но она должна дать представление о необходимых временных затратах. И да, данная оценка учитывает наличие специалиста, который будет руководить изменениями.

Если вы готовы выделить 20% рабочего времени ответственных сотрудников, вы справитесь с изменениями.

Наемные специалисты все сделают за вас

Привлечение специалистов по управлению бизнес процессами и изменениями будет очень полезно. Это существенно облегчит задачу. Однако нужно понимать, что сторонние специалисты не могут сделать все. Они не волшебники, у них нет универсальной кнопки или супер робота. Специалисты работают максимально эффективно тогда, когда работают в тесной связке с сотрудниками компании.

Подход «Мы платим, пусть они все делают», здесь не сработает. Вам придется помогать им. А они будут помогать вам. Это полностью взаимовыгодное сотрудничество.

Разделение ролей здесь очень простое. Специалисты владеют навыками и технологиями управления. Вы лучше всего знаете свой бизнес и свою отрасль.
Специалисты знают что и как делать в управлении. Вы знаете как и что делать в технологиях.

Специалисты не сделают все за вас. Только совместная работа приносит результат.

Сложно оценить эффект от управления бизнес процессами

Есть много способов оценки эффекта от внедрения управления бизнес процессами.
Самый простой – функционально стоимостной анализ.

Суть в следующем.
Когда известны все составляющие бизнес процесса, можно подсчитать стоимость его выполнения. Для расчета стоимости процесса учитывается:
– Затраты выполнение операций сотрудниками. Исходя из длительности операций и стоимости человека часа сотрудников.
– Затраты сырья и материалов
– Затраты на использование инструментов исходя из их срока эксплуатации
– Затраты на использование инфраструктуры. Если необходимо.
– Прочие производственные затраты. Например электроэнергия, вода и т.д.

Помимо этого списка могут учитываться и другие затраты. Тут зависит от особенностей сферы деятельности и компании.

Оценка стоимости выполнения процесса производится до изменений и спустя определенное время. Как правило, когда мы считаем, что изменения стали явными.

Разница в стоимости выполнения процесса и есть тот эффект, который вы получили.

Дополнительно можно рассчитать возврат на инвестиции в изменения процесса.
Для этого необходимо оценить затраты на изменения и поделить на разницу функционально стоимостного анализа до и после изменения. Таким образом вы получите количество повторений процесса, которое полностью компенсирует понесенные затраты. Если вас эта цифра устраивает – усилия приложены не зря))

Методы оценки эффективности использования управления бизнес процессами разнообразны, но при этом просты для применения.

Мы увидим результаты уже «завтра»

На самом деле – нет.
Любые изменения требуют времени. Сначала на организацию изменений. Затем на их реализацию, т.е. Непосредственно изменение процесса. Затем необходимо время, пока изменения полностью приживутся (или нет), а сотрудники начнут выполнять работу в соответствии с новым процессом.

Внедрение изменений всегда встречает сопротивление. И на его преодоление тоже требуется время.
Если вы пошли учиться плавать, это не значит, что завтра вы сможете спокойно проплыть несколько километров.

Разные изменения требуют разного времени. Некоторые внедрить очень просто – буквально за пару недель. Другие требуют годы. Соответственно эффект от изменений тоже будет виден на разных временных горизонтах.

Мы делим изменения на «быстрые» и «планомерные». Эффект от быстрых изменений виден не более чем через 2 месяца с момента внедрения. Все остальное – планомерные улучшения.

Миф о скорости изменений часто вредит компаниям. Когда до точки невозврата остается совсем чуть чуть, компания может сдаться. Важно уметь трезво оценивать возможную скорость изменений и получение эффекта.

Изменения не происходят быстро. Ни в жизни, ни в компаниях.

Не дайте себя обмануть, или Быстрый сыр, как правило, дурно пахнет

Любого специалиста, посвятившего себя Делу, возмущает шарлатанство. Я не исключение.
Управление бизнес процессами – это моя профессия, которой я посвятил основную часть трудовой деятельности. На этом пути были и выдающиеся успехи, и грандиозные провалы. И будет их еще больше. Это закономерное развитие профессионала. Знать всего невозможно, но 3 вещи я знаю наверняка:
1. Желающий получить все и дешево, получает ничего и дорого.
2. Методичность, последовательность и терпение всегда приносит свои плоды.
3. Только плохое происходит сразу. Все хорошее требует времени.

Поэтому:
– Трехдневные тренинги, гарантирующие увеличение продаж на 30% – шарлатанство
– Автоматизация бизнес процессов за неделю – обман
– Автоматизация процессов маркетинга – опасна, потому что автоматизируются только расчеты по грубым шаблонам.
– Двадцатипятилетний эксперт по оптимизации бизнес процессов – наглый авантюрист
– Если в одном предложении встречайте «управление бизнес процессами» и «CRM» – это про общедоступную CRM и больше ни про что.
– Если специалист по управлению бизнес процессами говорит вам что бизнес процесс это, «устойчивая целенаправленная совокупность взаимосвязанных видов деятельности, которые по определенной технологии преобразует входы в выходы, представляющие ценность для потребителя» – бегите от него!
– Анализ вашего бизнеса по сайту – все равно что лечить зубы по фотографии

Опасайтесь мифов и шарлатанов. Все модное становится предметом спекуляции.

Ведение бизнеса – это своего рода смесь игры в рулетку и в шахматы. От рулетки здесь события, на которые предприниматель не может повлиять, а от шахмат бесконечный анализ и прогнозирование ситуации. И именно анализу деятельности предприятия, руководитель должен уделять особое внимание. Одной из составляющих анализа является управление бизнес процессами.

Главные цели управления бизнес процессами

Для того, чтобы ответить на всех вопросы об управлении, нужно для начала определиться, что такое бизнес процессы на предприятии. По своей сути, это набор связанных задач и действий, которые прямо или косвенно приводят к главному результату – получению прибыли. Почти все, вплоть до организации работы клининговой службы, можно отнести к этой категории.

Теперь, когда с определениями покончено, нужно рассмотреть следующий аспект: что включает в себя управление бизнес процессами. Данную аналитическую работу можно разделить на три больших части:

1. Моделирование процесса;
2. Создание;
3. Улучшение.

На этапе моделирования, первоочередной задачей будет разграничение деятельности. Каждый конкретный отдел, должен выполнять свои задачи, список которых должен быть четко указан для начальников структурных подразделений. Именно на этом этапе решается, каким составом будет осуществляться работа над решением определенной задачи.

Этап создания всегда оказывается самым затратным. Здесь происходит создание и внедрение тех идей, на определенные которых направлен первый этап. Самый ответственный этап – сопоставление реальной ситуации с тем, что было в планах. Приведение реальности как можно ближе к «идеальной» ситуации, которая описана на бумаге.

На этапе улучшения начинается самая сложная и важная работа. Конечно, можно стоять на месте, год за годом демонстрируя свои отлаженные механизмы. Но конкуренты продолжают двигаться вперед, и чтобы быть на шаг впереди, нужно постоянно улучшаться. Для этого потребуется выделить группу специалистов, и одно ответственного за это направления. После нахождения способа оптимизации, потребуется его внедрение и последующий контроль за правильным выполнением. И цикл должен повториться снова.

На определенном этапе развития организации, для цикличного усовершенствования потребуется вливание «молодой крови». Сотрудников, которые помогут по-новому посмотреть на привычный мир внутри компании. Именно поэтому, необходимо либо расширять штат, либо подбирать на должность аналитиков вместе с опытными сотрудниками, молодых, которые могут посмотреть другими глазами на всё происходящее.

Современные методы совершенствования бизнес процессов

Для совершенствования бизнес процессов, используют различные методики. При этом исследователи выделяют пять самых актуальных:

• Быстрое принятие решений;
• Инжиниринг;
• Реинжиниринг;
• Перепроектирование определенного процесса;
• Бенчмаркинг.

Поговорим о каждом из методов подробнее. Они расположены в зависимости от влияния на компанию.

Быстрое принятие решений

Данную методику можно свести к словосочетанию «Мозговой штурм». Группа аналитиков ставит перед собой задачу улучшить работу определенного процесса на короткий срок – до 90 дней. Обычно на то, чтобы придумать рабочий метод уходит совещание, которые продолжается 1-2 рабочих дня. Руководство может как одобрить такое решение, так и отклонить. Из плюсов можно выделить оперативное принятие решение.

Минус – решение только локальных проблем. Чаще всего лечится далеко не сама причина, а лишь её последствия. Такой способ подойдет для консервативных организаций, которые не хотят чего-либо существенно менять

Бенчмаркинг

По своей сути, это анализ процессов других организаций, которые приняты за эталонные, и нахождение причин расхождения с текущей компанией. То есть, главная задача в этом случае – искать эталонную компанию, понять, как у нее работают процессы, чем они отличаются от наших и попытаться воссоздать те же условия. Плюсов много, но минус один и весомый – возможен перенос проблем. Нет наработанного годами плана работы.

Перепроектирование процесса

Один из самых интересных и важных способов управления. Применяется в отношении тех процессов, которые еще не изжили себя, но уже не могут в полной мере выполнять возложенные на них функции в связи с изменением рыночной ситуации или потребностей потребителя. Может использоваться во многих направлениях деятельности компании. Выполняет конкретные задачи, но тем не менее, только укрепляет текущую ситуацию, и не может радикально изменить структуру организации.

Инжиниринг

Самый спорный способ совершенствования в компании. Вокруг него идет множество споров и немало специалистов не могут определить, что конкретно в него входит. Но, во всеобщем понимании это все же проектирование компании «с чистого листа». Совершенно новый взгляд на вещи, который позволяет задать вектор развития, создать все процессы и решать новые задачи. Подходит этот метод только новым компаниям.

Реинжениринг

Как и предыдущий метод предполагает нечто глобальное. Но несмотря на это, подходит крупным корпорациям, которые хотят переосмыслить вектор своего развития. Революционный метод, который позволяет резко измениться, сделав огромный скачок вперед. Создан для того, чтобы полностью изменить все традиции и нормы, которые устоялись в организации. Уничтожение того, что не идет в ногу со временем, и «восстановление из пепла» — вот суть реинжениринга.

Перепроектирование процесса

Один из самых интересных и важных способов управления. Применяется в отношении тех процессов, которые еще не изжили себя, но уже не могут в полной мере выполнять возложенные на них функции в связи с изменением рыночной ситуации или потребностей потребителя.

Актуальность процесса совершенствования

Уже давно ясно, что организация без развития не сможет оказаться конкурентоспособной. И не только компания-новичок должна задумываться о том, как ей выйти на рынок, но и корпорации-ветераны просто обязаны тратить многомиллиардные состояния на постоянное улучшение всех своих бизнес процессов.

Для новой компании, совершенствование – отличный способ заявить о себе. Ведь то, что постоянно меняется, следуя за рынком, неизменно идет на волне популярности.

Другое дело, что не всегда в таких случаях можно создать свой стил. Именно поэтому следует держать тонкую грань между бесконечными изменениями и верностью традициям.

Компании же крупные, должны обязательно анализировать свою деятельность. При большом количестве ресурсов, можно упустить некоторые детали, и из-за невнимательно недополучить прибыль. Постоянный анализ дает возможность определять, что работает максимально, а что нет, оперативно решать возникающие проблемы и свободно чувствовать себя в условиях постоянной конкуренции.

Независимо от размера фирмы, постоянное совершенствование бизнес процессов – залог успешного развития и постоянного получения прибыли.

Рабочие программы для совершенствования бизнес процессов

В век сильной роботизации, мониторинг и анализ можно получить машинам. Ниже будет представлен топ 3 самых интересных программ для совершенствования бизнес процессов:

Aris Express

Достаточно простая и понятная программа для моделирования процессов организации. Упрощает внедрение различные систем, позволяет контролировать исполнение процессов, а также оптимизировать их стоимость. Представлена на русском языке. Есть русскоговорящая тех. Поддержка.

Business studio

Более глобальная программа для разработки и реализации стратегии. Платная версия позволяет реализовать как контроль за исполнением всех процессов, так и более мелкие задачи, вроде составления штатного расписания. Поможет распределить между сотрудниками всю необходимую документацию. Программа от русского производителя.

Fox Manager

Масштабная программа, которая позволяет полностью создать модель бизнес процессов на предприятии. Генерирует отчетность в режиме реального времени и предоставляет пользователю различные варианты решения. Отличается своей простотой, функционалом и доступностью. Есть версия на русском языке.

Существует множество программ вроде IBM business modeler, elma и прочих, которые также позволяют выполнять схожие задачи. Но они не настолько просты, и для работы потребуются специалисты, которые ранее осуществляли деятельность в этих программах.

В общем и целом, для тех, кто хочет постоянного совершенствования, быть активным и конкурентоспособным, подходит только путь постоянного совершенствования. А как его осуществлять – решать только руководству и сотрудникам компании.

Вконтакте

Системы управления бизнес-процессами (Business Process Management Systems - BPMS)

Решения в области Business Process Management (BPM) позволяют Вашей компании произвести оптимизацию бизнес-процессов, используя существующие приложения. Как правило, решение BPM - это комплекс открытых, основанных на стандартах компонентов для моделирования, выполнения, управления и оптимизации бизнес-процессов, а также интеграции корпоративных приложений.

Создаваемые в рамках интеграции приложений сервисы являются «кирпичиками», из которых можно строить последовательность выполнения в интегрированной системе «сквозных» бизнес-процессов, объединяющих процессы различных функциональных областей. Система BPM обеспечивает формирование последовательности автоматически выполняемых шагов бизнес-процесса и правил взаимодействия приложений (передачи информации) на каждом из этих шагов. Модули BPM ведущих производителей интеграционных платформ предоставляют возможность проектирования, разработки, тестирования, исполнения, отслеживания и управления бизнес-процессами. Приложения класса BPM служат удобным инструментом модификации интегрированной информационной системы в условиях изменения (реинжиниринга) бизнес-процессов предприятия.

Архитектура типового BPMS

Решения BPM используют инжиниринг закрытого цикла для выявления разрывов в процессах, что дает Вашей компании возможность контролировать полный жизненный цикл бизнес-процессов. В результате Вы получаете быструю и гибкую платформу, основанную на существующих приложениях, которая позволит вам оперативно реагировать на новые требования бизнеса и повышать производительность.

Системы управления бизнес-процессами обеспечивают существенные преимущества на двух уровнях. Первый уровень - стратегический, он включает такие преимущества, как связь между повседневной деятельностью компании и ее стратегическими установками. Второй уровень - количественный: это те преимущества, которые можно посчитать или измерить, например, экономия миллионов долларов или сокращение сроков, например, ввода и согласования договоров с дней до нескольких минут. И еще одно преимущество, может быть, самое важное - изменение атмосферы в коллективе, ориентация сотрудников на повышение эффективности их труда, информированность о том, как их действия влияют на общий результат и в целом на положение компании на рынке, а также более быстрая и активная реакция на изменения в конкурентной среде.

Области применения

В основе систем управления бизнес-процессами лежит процессный подход и они наилучшим образом подходит в первую очередь для автоматизации процессов ориентированных на клиента и сквозных бизнес-процессов Компании.

Чаще всего системы управления бизнес-процессами применяются при автоматизации сложных сквозных бизнес-процессов, включающих несколько подразделений компании и функции многих существующих информационных систем, подчиненных одной общей цели.

Другим распространенным случаем является автоматизация тех областей, для которых нет готовых, хорошо зарекомендовавших, либо относительно доступных готовых решений.

Также системы управления бизнес-процессами могут быть полезны при необходимости быстрой (от одного до нескольких месяцев), точечной автоматизации какого-либо критически важного бизнес-процесса Компании.

Ключевые функции

Функциональная архитектуры BPM

Все предлагаемые на данный момент системы управления бизнес-процессами (BPMS), вне зависимости от платформы реализации, предоставляют следующие основные функции:

• управление задачами сотрудников (возможность объединять отдельные задачи в бизнес-процессы, управлять переходами от одной задачи к другой, переназначать задачи и назначить их на группы, функциональные подразделения);
• возможность оперативно отслеживать ход исполнения задач (текущую стадию, исполнителя и состояние процесса, а также историю изменений);
• оперативный мониторинг (в режиме реального времени) основных показателей процессов, вывод предупреждений об ошибках и падении показателей;
• возможность подключения к системе партнеров (например, коллекторских агентств, партнеров по оценке и т.д.) и полный контроль за их деятельностью со стороны сотрудников Вашей компании (сотрудники видят на какой стадии находится процесс и задачи партнеров);
• построение жестко регламентированных для всех сотрудников бизнес-процессов (решение о переходе на следующую фазу принимает система, на основании уже введенных данных и логики бизнес-процесса);
• разграничение доступа на основе роли каждого из пользователей в процессе (сотруднику доступны только его задачи и только те данные которые необходимы для выполнения задачи);
• интеграция с другими корпоративными системами прямо во время исполнения бизнес-процесса (получение и передача данных);
• управление бизнес-правилами не останавливая выполнения бизнес-процессов (например, сроком удовлетворения требования о полном досрочном погашении, максимальным сроком инициации искового производства по кредитному делу и т.д.)

Преимущества внедрения процессно-ориентированой системы управления бизнес-процессами

Ключевыми особенностями именно BPM-решений является то, что они позволяют:

• обеспечить гибкую автоматизацию «сквозных» бизнес-процессов (затрагивающих функционирование нескольких функциональных подразделений компании и информационных систем);
• дают основу для внедрения процессного подхода к организации работ организационных единиц предприятия;
• позволяют организовать эффективный контроль за выполнением бизнес-процессов в режиме реального времени;
• снижают издержки на взаимодействие между различными подразделениями компаниями и партнерами;
• обеспечивают «бесшовную» интеграцию между различными бизнес-приложениями предприятия и партнеров;
• позволяют уменьшить срок внедрения новых решений и бизнес-функций;
• повышают отдачу от уже сделанных инвестиций в информационные системы компании.

Подходы к реализации

Специалисты компании Tops BI обладают компетенцией и опытом создания интеграционных решений на промышленных платформах ведущих мировых производителей:

Oracle SOA Suite/Oracle BPM Suite;

SAP NetWeaver BPM;

Microsoft SharePoint и BizTalk Server.

Непосредственно перед началом реализации может быть проведено обследование бизнес-процессов Вашей компании как специалистами TopS BI, так и использованы уже формализованные Вашими специалистами в каком-либо средстве бизнес-процессы (в качестве используемых средств описания могут использовать Aris или Visio).

Компания TopS BI предоставляет следующие услуги при построении систем управления бизнес-процессами:

• проведение комплексного обследования, включающего анализ бизнес-процессов и ИТ-инфраструктуры компании для формирования последующих предложений по построению интеграционного решения;
• разработка архитектуры интеграционного решения;
• проектирование программно-аппаратного комплекса, подготовка спецификаций на необходимое оборудование и программное обеспечение, поставка, установка и настройка программно-аппаратного комплекса для интеграционного решения.
• разработка компонент бизнес и интеграционной логики, пользовательского интерфейса;
• настройка и адаптация средств мониторинга бизнес-процессов, информационной безопасности и администрирования;
• создание и доработка компонент расширяющих возможности существующих интеграционных решений;
• разработка эксплуатационной документации и проведение обучения пользователей системы;
• комплексное тестирование интеграционного решения;
• обеспечение технической поддержки и сопровождения реализованных решений.