Информационные технологии управления / Лекции / 4.4.Организация внедрения корпоративных систем

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

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

Нулевой цикл включает:

предварительное обследование и оценку состояния (предпроектное обследование);

предварительную переподготовку;

техническое задание;

технико-экономическое обоснование;

организацию проекта;

выработку целей.

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

Предпроектное обследование

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

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

№ и наименование процесса;

№ и наименование процесса верхнего уровня;

№№ и наименования вложенных детальных процессов следующего уровня;

10

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

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

события, инициирующие процесс;

события, завершающие процесс;

перечень функций процесса;

перечень функций, контролирующих выполнение процесса;

перечень входящих документов;

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

перечень исходящих документов;

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

перечень подразделений и должностей, участвующих в процессе;

типы используемых систем автоматизации.

На основе исследований строятся модели ―as is‖ (как есть) и ―to be‖ (как должно быть). Реорганизация представляет собой переход от одной модели к другой и позволяет навести элементарный порядок в организации процессов.

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

схема бизнес-процессов ―as is‖;

схема бизнес-процессов ―to be‖;

бизнес-план реорганизации;

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

Как правило, руководство фирмы-заказчика требует также определить приблизительную продолжительность и стоимость проекта.

Предварительная переподготовка

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

11

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

Руководителю предприятия следует понимать, что процесс обследования почти наверняка будет воспринят персоналом ―в штыки‖. Во-первых,

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

Пример из жизни:

– Петрович (зав. складом), отпусти ―Кентавру‖ (покупатель). Я

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

платят налом.

–Нельзя.

–Да ты что? Всегда же так делали.

–А теперь шеф штрафует. Все – через компьютер.

–Во программеры… Дармоеды очкастые. Работать не дают. Разогнать

бы!

Действовать предлагается не ―по понятиям‖, а по правилам. Для носителей российского менталитета это всегда тяжелое испытание (―Что я, сам не знаю, как лучше делать?‖).

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

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

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

12

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

стоящие на пути прогресса, будут неизбежно размолоты жерновами истории.

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

Техническое задание – набор документов и спецификаций,

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

В него входят:

требования к автоматизированным рабочим местам, их составу и структуре;

разработка требований к программным средствам;

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

требования к секретности и защите информации.

Процессы системы делятся на:

ручные (регламентируются, но не автоматизируются);

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

диалоговые (подавляющее большинство процессов в современных АСУП);

процессы реального времени.

Для автоматизированных процессов конкретизируются требования к виду

иформе документов.

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

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

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

Технико-экономическое обоснование

13

Анализ ―затраты-эффект‖ позволяет принимать обоснованные решения и подтверждает финансовую необходимость изменений.

Для систем MRP/ERP козырная карта ТЭО – управление запасами и логистика. В результате внедрения существенно уменьшаются запасы на складах, сокращается цикл производства, исчезает дефицит товаров и комплектующих и т. д. Все эти преимущества имеют строгое количественное выражение (стоимость аренды складских помещений, затраты на перевозки и др.). В результате расчет экономического эффекта становится делом техники и ТЭО выглядит вполне убедительно.

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

Менее благополучно дело обстоит с внедрением бухгалтерских модулей.

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

―плохую‖ бухгалтерскую систему на ―хорошую‖? Например, повышение качества учета. Адекватная бухгалтерская система ―организует‖ работающего в ней бухгалтера.

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

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

―официальной учетной политикой предприятия‖.

Установка на таком предприятии хотя бы ―1С‖ ведет к уничтожению существующей бухгалтерской ―матрицы‖ и вносит некоторый учетный порядок. Однако единственный аргумент в пользу внедрения – необходимость полностью перестраивать учет в случае ухода ―концептуального главбуха‖.

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

14

На первый взгляд, значительно проще обстоит дело с взаиморасчетами

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

–уменьшается вероятности ошибки (особенно если расчеты многовалютные);

–руководство в любой момент имеет доступ к исчерпывающей информации о положении дел;

–существует возможность в режиме реального времени отслеживать должников и своевременно принимать меры.

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

– в обратном случае) расчету практически не поддается.

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

Организация проекта

Существуют три уровня организации проекта (для больших

предприятий):

Управляющий комитет (руководитель компании и его заместители). Регулярные совещания 1-2 раза в месяц. Определяет стратегию, ресурсы, принимает основные решения.

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

15

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

производственным направлениям и программам. Осуществляет контроль на уровне фирмы и ее отделов. Члены команд могут работать над

отдельными задачами.

Важнейшая цель организации проекта – вовлечение сотрудников

компании-клиента в процесс внедрения. Это достигается через распределение ответственности. Персонал отвечает за автоматизацию своих участков.

Оптимальная структура рабочей команды:

сотрудник (сотрудники) заказчика, работающие на данном участке. Задачи: консультировать ИТ специалистов, осуществлять

текущий контроль и предварительную приемку внедряемых объектов

(формы, документы, отчеты и т. д.);

сотрудник (сотрудники) отдела информационных технологий

(ОИТ) заказчика. Задачи: освоить в необходимом объеме инструментальные средства исполнителя (―1С‖, ―Галактика‖, Scala, R3 и

др.), участвовать в доводке и разработке автоматизированной системы,

служить информационным ―буфером‖ между сотрудниками клиента и

консультантами исполнителя;
консультанты-программисты			исполнителя.	Задачи:
разработать,	внедрить,	адаптировать	необходимые	модули,

консультировать сотрудников ОИТ заказчика.

Использование в разработке и внедрении сотрудников ОИТ компании-

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

Причины:

сотрудники ОИТ так или иначе уже проводили автоматизацию своего предприятия и обладают ценным ―know-how‖,

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

16

действительно хорошо освоить систему сотрудники могут,

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

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

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

(кодирования). Консультантам остается осуществлять ―чуткое руководство‖

(что тоже весьма непросто) и разбираться с тонкостями и сложностями процесса.

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

Выработка целей

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

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

Например, данные управленческого учета, необходимые руководителям для принятия решений, могут ―пылиться‖ где-нибудь в экономическом отделе,

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

―работает‖.

17

Данные, как товар, не должны просто лежать где-то в компании. Их надо довести до конечных пользователей, причем желательно – пока данные свежие.

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

рассматривают ее как важнейший элемент стратегического развития.

“Клиент готов”

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

положение дел на предприятии прояснено, договор утвержден, и служащие уже с нетерпением ожидают прихода ―внедренцев‖.

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

Технический проект

Технический проект (техническое предложение, ТП) – это набор документов и спецификаций, описывающих конструкцию, архитектуру,

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

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

спецификации каждого компонента, интерфейсы между компонентами,

требования к тестам, план интеграции компонентов.

В российской практике результаты предпроектного обследования,

техническое задание и технический проект часто сводятся в один документ

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

Начальная переподготовка

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

В первую очередь, следует определить предметных экспертов –

18

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

Большое значение имеет переподготовка по обеспечению необходимой точности данных (см. ниже ―Управление данными‖).

Планирование

Как правило, на предприятии существуют два плана автоматизации:

стратегический и оперативный.

Стратегический план содержит базовые принципы, в том числе:

цели;

способ автоматизации (комплексная, кустовая и т. д.);

долгосрочную техническую политику (стандарты и т. д.);

ограничения (финансовые, временные и т. д.).

Стратегия автоматизации должна соответствовать общей стратегии бизнеса.

В некоторых компаниях с большим успехом использовался подход,

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

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

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

Критическими факторами успеха для того же предприятия могут быть:

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

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

19