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

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

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

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

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

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

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

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

наличие четко сформулированных целей проекта и требований к ИС;

наличие стратегии внедрения и использования ИС;

проведение предпроектного обследования предприятия и построения моделей "Как есть" и "Как будет";

планирование работ, ресурсов и контроль выполнения плана внедрения;

участие высшего руководства во внедрении системы;

проведение работ по внедрению ИС специалистами по интегрированию систем совместно со специалистами предприятия;

регулярный мониторинг качества выполняемых работ;

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

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

максимально формализовать цели проекта внедрения ИС;

оценить минимально необходимые затраты и статьи расхода;

установить высокий приоритет проекта внедрения перед остальными текущими проектами;

наделить руководителя проекта максимально возможными полномочиями;

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

разработать организационные меры для применения новых информационных технологий;

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

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

организационное управление;

организационно-административное обеспечение;

управление бизнес-процессами;

управленческий, планово-финансовый и бухгалтерский учет;

управление персоналом;

управление документацией;

управление материально-техническим обеспечением;

управление связями с клиентами и внешней средой.

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

системная платформа - внедрение и адаптация готового решения от производителя или разработка на заказ в соответствии с техническим заданием заказчика;

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

адаптируемость - система настраивается в соответствии с требованиями заказчика и на особенности информационного поля заказчика;

распределенность - система может эффективно функционировать в территориально удаленных подразделениях и филиалах предприятия;

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

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

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

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

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

· наличие четко сформулированных целей проекта и требований к ИС;

· наличие стратегии внедрения и использования ИС;

· проведение предпроектного обследования предприятия и построения моделей "Как есть" и "Как будет";

· планирование работ, ресурсов и контроль выполнения плана внедрения;

· участие высшего руководства во внедрении системы;

· проведение работ по внедрению ИС специалистами по интегрированию систем совместно со специалистами предприятия;

· регулярный мониторинг качества выполняемых работ;

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

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

· максимально формализовать цели проекта внедрения ИС;

· оценить минимально необходимые затраты и статьи расхода;

· установить высокий приоритет проекта внедрения перед остальными текущими проектами;

· наделить руководителя проекта максимально возможными полномочиями;

· провести массовую просветительскую работу с персоналом предприятия с целью довести до каждого важность и необходимость предстоящих преобразований;

· разработать организационные меры для применения новых информационных технологий;

· распределить персональную ответственность по всем этапам внедрения и опытной эксплуатации.

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

· организационное управление;

· организационно-административное обеспечение;

· управление бизнес-процессами;

· управленческий, планово-финансовый и бухгалтерский учет;

· управление персоналом;

· управление документацией;

· управление материально-техническим обеспечением;

· управление связями с клиентами и внешней средой.

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

· системная платформа - внедрение и адаптация готового решения от производителя или разработка на заказ в соответствии с техническим заданием заказчика;

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

· адаптируемость - система настраивается в соответствии с требованиями заказчика и на особенности информационного поля заказчика;

· распределенность - система может эффективно функционировать в территориально удаленных подразделениях и филиалах предприятия;

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

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

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

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

· формирование проектной и экспертной групп;

· распределение полномочий и ответственности;

· определение организационно-технических требований к процессу внедрения;

· уточнение спецификаций и ожиданий заказчика;

· обучение группы внедрения, состоящей из специалистов предприятия-заказчика.

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

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

· формируется и утверждается концептуальный проект;

· уточняются и конкретизируются цели и задачи проекта;

· определяются размеры прототипа системы;

· согласуются укрупненный план работы, последовательность этапов и условия опытной эксплуатации, планово-финансовые и отчетные показатели;

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

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

Рисунок 12 - Примерное содержание репозитория проекта внедрения

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

Рисунок 13 - Примерный состав документации по процессу внедрения информационной системы

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

После окончания фазы реализации проект внедрения считается законченным. Информационная система передается в эксплуатацию.

Контрольные вопросы

1. Что такое "открытая информационная система"? Перечислите основные свойства открытых систем.

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

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

4. Какие программные средства используются для моделирования процессов при разработке информационных систем?

5. На основании каких данных и информации разрабатываются модели состояния AS IS и AS TO BE?

6. Кто в компании занимается вопросами разработки, внедрения и развития ИС? Кто участвует в подготовке технического задания на разработку ИС?

7. Назовите основные этапы проектирования информационных технологий.

8. Перечислите этапы жизненного цикла информационной системы.

9. На каком этапе разработки и внедрения ИС производится обучение персонала компании?

10. Перечислите основные фазы внедрения ИС.

Введение

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

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

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

Автоматизация работы конструкторов и технологов начиналась с развития АРМ (автоматизированных рабочих мест), то есть средств для решения инженерных задач и выпуска соответствующей документации. Когда в электронном виде стали появляться большие объемы информации, появилась потребность управлять этой информацией – на сцену начали выходить PDM- и PLM-системы. Таким образом, результаты работы локальных средств автоматизации интегрируются третьей системой, а локальные АРМ получают возможность пользоваться общей справочной информацией.

В нашем случае мы имеем дело с принципиально иным способом работы с конструкторской и технологической информацией. Система TechnologiCS (а в дальнейшем речь пойдет именно о ней) представляет собой прежде всего централизованное хранилище информации об изделиях (базу данных). С этой точки зрения она очень похожа на традиционные системы управления предприятием (АСУП). Тем не менее есть и существенное отличие, позволяющее преодолеть традиционный изъян подобных систем – недостаточную актуальность данных и часто возникающую необходимость в повторном вводе информации. TechnologiCS предоставляет владельцам информации – конструкторам и технологам – возможность непосредственной работы с базой данных. При этом доступ к базе осуществляется через удобный интерфейс, в каждом конкретном случае ориентированный на выполнение определенной функции (аналогично АРМ); предусмотрены и все необходимые средства автоматизации для решения инженерных задач.

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

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

Процессный подход

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

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

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

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

Функциональное и процессное внедрение ИС

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

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

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

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

Говоря о процессном внедрении, нельзя не упомянуть об инструментарии, применяемом для моделирования бизнес-процессов. Сам по себе процессный подход не предъявляет особых требований к инструментам описания и проектирования бизнес-процессов, однако использование специализированных инструментов вместо стандартных офисных программ имеет массу неоспоримых преимуществ. Среди множества представленных на рынке инструментальных средств наиболее эффективным следует, пожалуй, признать программный продукт ARIS (этот вывод подтверждается результатами исследований, опубликованными Gartner Group в январе 2004 г.). ARIS (Architecture of integrated Information Systems – архитектура интегрированных информационных систем) представляет собой методологию и базирующееся на ней семейство программных продуктов, разработанных компанией IDS Scheer. Чтобы дать некоторое представление об ARIS, перечислим ее основные преимущества:

представление бизнес-процессов в виде графических моделей;

наличие единого стандарта моделирования;

ориентация на процессный подход;

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

возможность генерации разнообразных отчетов по разработанной модели – в том числе и отчетов, специально разработанных пользователем;

возможность организации совместной работы в сетях Internet и Intranet.

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

Информационная система и процессный подход

Рассмотрим несколько типичных случаев автоматизации на производственном предприятии.

Отсутствие автоматизации.

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

Основной носитель информации – документ, обработка информации носит последовательный характер.

На предприятии действует автоматизированная система управления (АСУП).

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

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

Варианты с использованием локальных средств автоматизации.

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

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

Что же дает внедрение системы TechnologiCS в плане применения процессного подхода и совершенствования бизнес-процессов?

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

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

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

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

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

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

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

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

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

Опыт реальных проектов

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

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

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

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

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

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

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

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

подготовка проекта;

концептуальное проектирование;

реализация;

заключительная подготовка;

ввод в эксплуатацию и поддержка.

На этапе подготовки определяются стандарты проекта (в том числе стандарты моделирования бизнес-процессов), выполняется моделирование бизнес-процессов «как есть». Детальность проработки модели и необходимые для этого ресурсы в значительной мере определяются состоянием предприятия.

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

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

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

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

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

В рамках этой статьи мы ограничимся обзором первых двух этапов внедрения системы на Новосибирском заводе химконцентратов.

Подготовка проекта

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

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

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

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

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

Концептуальное проектирование

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

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

Результатом работы на этом этапе стало появление детально проработанного документа «План перехода к процессам "как должно быть"» (рис. 5).

Краткие выводы

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

Моделирование бизнес-процессов наиболее эффективно с применением специализированных инструментов и проверенных методологий.

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

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

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

Вопрос: «Кто осуществит внедрение информационной системы?», чрезвычайно важен в каждом из случаев запуска проекта автоматизации.

Данный тезис неоспорим, по нескольким причинам:

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

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

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

Внедрение осуществляет компания-внедренец;

1. Собственный отдел информационных технологий;
2. Привлекается фрилансер, который выполняет функцию руководителя проекта.

Рассмотрим каждый вариант подробнее.

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

Нюансы работы с крупной компанией внедренцем:

Внедрение информационной системы поставлено на поток;

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

Неудача на «небольших» проектах мало влияет на общую репутацию компании и отношения к таким проектам соответствующее;

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

Стоимость услуг – самая высокая из всех рассматриваемых вариантов.

Альтернативный вариант – небольшая компания:

Проект может стать приоритетной задачей для специалистов компании;

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

Успех проекта полностью зависит от квалификации сотрудников компании и в первую очередь менеджера проекта;

Обходятся значительно дешевле чем.

Собственный отдел информационных технологий (ИТ).

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

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

Еще одним моментом является слишком тесная коммуникация, пользователь просит что-то сделать устно, однако потом вносит коррективы, а потом еще. Таким образом, пропадает мера оценки работы и консультанта и программиста. Сложно попасть, когда цель не задана.

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

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

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

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

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

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

Делая выводы из всего вышесказанного, хочется зафиксировать:

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

Исходя из того, что предложенные способы не идеальны.

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

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

Это один из основных вопросов для любого проекта вообще. Заказчик зачастую выбирает цель, которая не имеет к информационной системе никакого отношения, или же зависит от нее незначительно. Примеры: увеличение продаж, занятие большей доли рынка, создание другой культуры управления предприятием и т. д. Но если компания производит товар, спрос на который падает – как тут поможет информационная система? Проблему здесь должно решать подразделение маркетинга. Если нужно изменить культуру предприятия – это вопрос управления персоналом и генерального директора. У некоторых, однако, теплится надежда, что стоит отдать деньги за информационную систему - и проблемы, связанные с организаций бизнеса, решатся сами собой. Обещания продавцов, «впаривающих» дорогие, иностранного производства, многократно проверенные и построенные на «лучших мировых бизнес-практиках» системы лишь укрепляют эту веру. Но на деле компания с неэффективным стилем управления останется неэффективной, только уже с информационной системой. Если на вашу продукцию упал спрос, он тоже не изменится никак. Правда, информационная система позволит вам быстро и точно подсчитать убытки, в том числе и от ее внедрения.

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

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

Даже если предположить, что специалисты-информационщики знают, как следует изменить бизнес-процессы (с логикой у нас порядок), у них все равно нет нужного административного ресурса, да и ожидаемый результат зависит, в первую очередь, не от программного обеспечения. Здесь явно путается следствие и причина. Допустим, есть предприятие А с информационной системой ABC. Предприятие работает стабильно, нет авралов, неразберихи, заказы выполняются в срок, есть планомерная деятельность отлаженного механизма. Можно сделать вывод, что все хорошо благодаря системе ABC, но это 100% не так. Наличие системы ABC у предприятия A, кончено же, вносит свой вклад в бизнес, но не является ключевым. Если руководство некоего предприятия Б решило внедрить у себя систему ABC в надежде, что после ее внедрения предприятие Б тоже будет работать так же, как A, его ждет сюрприз. Деньги будут потрачены, но ожидаемый эффект не наступит, т.к. методика работы на предприятии Б не изменится.

Эффективные цели

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

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

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

Техническое задание

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

Получается, что не заказчик подписал неподходящее ТЗ, а исполнитель разработал и предложил совсем не то – не угадал, о чем мечтал заказчик. Замечаете парадокс? Исполнитель сам для себя пишет ТЗ, но при этом должен угадать, чего на самом деле хочет заказчик. В принципе, это возможно (для участников шоу «Битва Экстрасенсов»), но маловероятно. У меня был опыт создания подробных ТЗ, которые на этапе внедрения претерпевали изменения порядка 30%. Обычная история: в процессе работы над проектом у заказчика появлялись новые идеи, их приходилось учитывать, отказываясь от предыдущих решений. Потому я не сторонник очень подробных ТЗ. Они отнимают много времени, а в итоге будут скорректированы на этапе опытной эксплуатации и внедрения. Если не сделать корректировку, можно испортить отношения с заказчиком. При попытке сослаться на подробное ТЗ в ответ вы услышите – «ну, вы же специалисты, должны были сами все знать заранее».

Я считаю, в ТЗ должны быть отражены только общие блоки работ с описанием ожидаемых результатов. Пусть оно достаточно точно описывает, что хочет получить заказчик, и что должен сделать исполнитель. Корректировка ТЗ неизбежна из-за того, что при появлении нового инструмента у заказчика обязательно появятся новые бизнес-процессы. Попытка сохранить прежние бизнес-процессы приведет к провалу проекта. Конечно, не все старое отметается полностью, оно корректируется в соответствии с возросшими возможностями предприятия при наличии информационной системы. Максимум, на чем должно останавливаться ТЗ – списки документов для обработки системой с их образцами. Таким образом, составленное ТЗ не изменится по части общих требований, фактически оно будет уточняться в процессе внедрения, вплоть до конкретных полей и процессов. При этом исполнитель в любом случае знает ожидаемый объем работ. Для успешного проекта требуется 1-2 итерации: внедряется определенный объем выполненных работ, и по результатам заказчик согласовывает коррекцию с исполнителем. Время, которое можно было потратить на излишнюю детализацию ТЗ, гораздо эффективнее использовать для итерационных корректировок системы в соответствии с результатом тестовой эксплуатации.

Есть еще один вариант составления ТЗ: в нем декларируется конечная цель заказчика. И тут вы можете сразу заметить противоречия с предыдущем написанным тестом. Это случай составления проекта, в котором информационная система является только частью. У меня был опыт внедрения комплексной системы управления компаний, где основная сумма по контакту выплачивалась в случае, если заказчик получит увеличение оборота в два раза. Спрашивается, это как? Ответ прост: цели заказчика - автоматизация и оптимизация бизнес процессов копании, ускорение процесса работы с клиентами, точный учет затрат по контрактам, точный расчет бонусов менеджерам, участвующим в контрактах, финансовое планирование. Исходя из того, что все эти задачи не были решены, я подписал контракт. К сожалению, достигнуть 100% увеличения объема оборота у заказчика за 1 год не удалось, но 83% тоже хорошо. Мое вознаграждение было выплачено пропорционально.

Следующим важным документом для успешного выполнения работ является план-график работ.

План-график работ

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

Запуск системы в работу

Запуску системы предшествует тестирование исполнителем системы на примерах заказчика. После получения положительных результатов начинается работа по реальному внедрению и запуску системы. Если опытная эксплуатация делается только на опытных примерах без участия рядовых исполнителей заказчика, без использования реальных задач, она не достигнет поставленной цели. Целью же является сбор замечаний, которые необходимо устранить для перевода в промышленную эксплуатацию. Данный этап правильнее было бы назвать расширенным тестированием с привлечением исполнителей заказчика. Реальная опытная эксплуатация начинается после внедрения системы при участии, как минимум, 50-70% процентах рабочих мест.

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

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

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

• Тестирование с привлечением сотрудников заказчика на реальных примерах;
• Опытная эксплуатация с немедленным устраняем возникающих проблем;
• Промышленная эксплуатация.

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

Теги: Добавить метки