План внедрения: новое и забытое старое
Пищиков С. В.
project manager, "Ш.ЭЙР-С"
Вступление
В конце 70-х годов в Америке появился новый (по тем временам) прогрессивный стандарт MRP. Его возникновение и массовое использование стало ответом на хлынувший в Штаты поток дешевых японских автомобилей и угрозу знаменитому американскому автомобилестроению. Внедрение новой концепции позволило значительно повысить эффективность производства и уменьшить себестоимость выпускаемой продукции.
Практическая реализация стандарта невозможна без внедрения комплексной системы автоматизации. Один из разработчиков MRP Оливер Уайт предложил и стал широко применять подробный план внедрения программ комплексного управления предприятием (MRP-программ).
Этот план был проверен опытом тысяч компаний в течение 20 с лишним лет. Он широко использовался для внедрения MRPII, ERP и других технологий, так что сам стал фактически стандартом. В дальнейшем мы будем называть его планом Уайта.
Рассмотрим план Уайта подробнее, сравним его с российским ГОСТом и планами внедрения некоторых известных ИТ-компаний (Scala, Галактика, ЭпикРус и др.). Проанализируем приемы внедрения ПО, разработанного методом "экстремального программирования".
План Уайта
Первые шесть этапов проекта составляют так называемый нулевой цикл. По их результатам принимается решение о внедрении. До недавнего времени нулевой цикл создавал много проблем. Заказчик не понимал, за что он должен платить, а ИТ-компании не могли или не хотели самостоятельно финансировать этот недешевый этап.
Сегодня клиенты все чаще признают необходимость оплаты нулевого цикла, независимо от его результатов. Скорее всего, это связано с накопленным опытом неудачных внедрений у себя и "соседей".
Нулевой цикл включает:
- предварительное обследование и оценку состояния (предпроектное обследование);
- предварительную переподготовку;
- техническое задание;
- технико-экономическое обоснование;
- организацию проекта;
- выработку целей.
Рассмотрим каждый этап подробнее.
Предпроектное обследование
В настоящее время предварительное обследование проводят почти все ИТ-компании (за исключением очень маленьких и неопытных). Группа консультантов исследует предприятие-клиент, собирает детальную информацию о его структуре и организации деятельности. Полученные данные систематизируются и анализируются.
С помощью специализированных средств (например BPWin) строится диаграмма бизнес-процессов (обычно - в нотации DFD), каждый из которых характеризуется объемным блоком информации:
- № и наименование процесса;
- № и наименование процесса верхнего уровня;
- №№ и наименования вложенных детальных процессов следующего уровня;
- текстовое описание процесса;
- перечень выходов процесса (документы, файлы, материальные ресурсы, являющие результатом выполнения процесса);
- события, инициирующие процесс;
- события, завершающие процесс;
- перечень функций процесса;
- перечень функций, контролирующих выполнение процесса;
- перечень входящих документов;
- перечень входящих материальных ресурсов;
- перечень исходящих документов;
- перечень исходящих материальных ресурсов;
- перечень подразделений и должностей, участвующих в процессе;
- типы используемых систем автоматизации.
На основе исследований строятся модели "as is" (как есть) и "to be" (как должно быть). Реорганизация представляет собой переход от одной модели к другой и позволяет навести элементарный порядок в организации процессов.
В наиболее полном случае результатом предпроектного обследования являются следующие документы:
- схема бизнес-процессов "as is";
- схема бизнес-процессов "to be";
- бизнес-план реорганизации;
- краткосрочный план действий.
Как правило, руководство фирмы-заказчика требует также определить приблизительную продолжительность и стоимость проекта.
Предварительная переподготовка
Цель - объяснить высшему руководству, что представляет собой процесс внедрения. Важно преодолеть различия в понимании процесса разными категориями сотрудников. Руководители должны придти к единому видению результатов и необходимых ресурсов.
К сожалению, значение этого этапа часто недооценивается консалтинговыми и ИТ-компаниями, что создает ряд сложнейших проблем.
Руководителю предприятия следует понимать, что процесс обследования почти наверняка будет воспринят персоналом "в штыки". Во-первых, специалистам придется отвлекаться от работы, выполнение которой с них, тем не менее, будут требовать. Во-вторых, произойдет ломка межличностных отношений, которые подчас являются капиталом, результатом многолетних усилий сотрудников.
Пример из жизни:
- Петрович (зав. складом), отпусти "Кентавру" (покупатель). Я накладную попозже занесу, не хочу клиента заставлять ждать: берут много, платят налом.
- Нельзя.
- Да ты что? Всегда же так делали.
- А теперь шеф штрафует. Все - через компьютер.
- Во программеры Дармоеды очкастые. Работать не дают. Разогнать бы!
Действовать предлагается не "по понятиям", а по правилам. Для носителей российского менталитета это всегда тяжелое испытание ("Что я, сам не знаю, как лучше делать?").
Описывая рабочие процессы, сотрудники подсознательно представляют не то, что есть на самом деле, а то, что им хотелось бы видеть. И очень обижаются, когда им указывают на это. Многие воспринимают "дознание" такого рода как "подсиживание" и поиск недостатков.
Есть ряд других проблем, но на них мы не будем сейчас останавливаться.
Вышесказанного достаточно, чтобы понять: сколько-нибудь глобальные вмешательства в деятельность компании требуют работы психолога, который поможет создать в коллективе атмосферу максимально благоприятного отношения к исследованиям. Нередко такие функции приходится брать на себя руководителю проекта. Полезно проводить исторические параллели, рассказывая, например, о движении луддитов и прозрачно намекая, что люди, стоящие на пути прогресса, будут неизбежно размолоты жерновами истории.
Техническое задание
Техническое задание - набор документов и спецификаций, определяющих требования к информационной системе и ее функциональности. В него входят:
- требования к автоматизированным рабочим местам, их составу и структуре;
- разработка требований к программным средствам;
- разработка топологии, состава и структуры локальной вычислительной сети;
- требования к секретности и защите информации.
Процессы системы делятся на:
- ручные (регламентируются, но не автоматизируются);
- пакетные (как правило, сбор статистических данных, получение отчетности за период, пересчеты глобальных регистров);
- диалоговые (подавляющее большинство процессов в современных АСУП);
- процессы реального времени.
Для автоматизированных процессов конкретизируются требования к виду и форме документов.
В составлении ТЗ принимают участие ИТ-специалисты, в частности разработчики, обладающие необходимым опытом и владеющие терминологией. Результат - подробный официальный документ, в котором отражены перечисленные выше требования или их допустимое подмножество. После составления технического задания можно реально оценить сроки и стоимость реализации проекта.
Формально составление технического задания - работа заказчика, однако в большинстве случаев этим занимается фирма, проводящая внедрение.
Технико-экономическое обоснование
Анализ "затраты-эффект" позволяет принимать обоснованные решения и подтверждает финансовую необходимость изменений.
Для систем MRP/ERP козырная карта ТЭО - управление запасами и логистика. В результате внедрения существенно уменьшаются запасы на складах, сокращается цикл производства, исчезает дефицит товаров и комплектующих и т. д. Все эти преимущества имеют строгое количественное выражение (стоимость аренды складских помещений, затраты на перевозки и др.). В результате расчет экономического эффекта становится делом техники и ТЭО выглядит вполне убедительно.
В то же время определение и количественная оценка некоторых статей расходов до сих пор вызывает трудности даже за рубежом. Отчасти задача решается методом аналогий.
Менее благополучно дело обстоит с внедрением бухгалтерских модулей.
Какую экономическую выгоду получит предприятие, если заменит "плохую" бухгалтерскую систему на "хорошую"? Например, повышение качества учета. Адекватная бухгалтерская система "организует" работающего в ней бухгалтера.
Знакомясь с учетом клиента, нередко обнаруживаешь сотни фантастических субсчетов (заменяющих аналитику), диковинные отчеты, созданные под мудрым руководством, какой-нибудь Марьи Ивановны. Все это согласовано с представителем налоговой инспекции и гордо именуется "официальной учетной политикой предприятия".
Установка на таком предприятии хотя бы "1С" ведет к уничтожению существующей бухгалтерской "матрицы" и вносит некоторый учетный порядок. Однако единственный аргумент в пользу внедрения - необходимость полностью перестраивать учет в случае ухода "концептуального главбуха".
Понятно, что консультант, указавший такие причины, автоматически оказывается в конфронтации с главным бухгалтером. А это, мягко говоря, не полезно.
На первый взгляд, значительно проще обстоит дело с взаиморасчетами (поставщики, покупатели, авансы, дебиторы, кредиторы и т. д.). Три основных аргумента в пользу автоматизации:
- уменьшается вероятности ошибки (особенно если расчеты многовалютные);
- руководство в любой момент имеет доступ к исчерпывающей информации о положении дел;
- существует возможность в режиме реального времени отслеживать должников и своевременно принимать меры.
Однако и тут не все гладко. Чтобы количественно оценить потери от ошибок, надо заранее получить полную информацию по клиенту и его финансовой истории. До подписания договора это нереально. Ущерб от несвоевременных действий вследствие недостатка информации (как и прибыль - в обратном случае) расчету практически не поддается.
Многие так называемые "точные данные" приводятся ИТ-компаниями в основном для психологического эффекта. Общие слова и цифры, результаты статистики вряд ли могут произвести на руководство заказчика сильное впечатление.
Организация проекта
Существуют три уровня организации проекта (для больших предприятий):
- Управляющий комитет (руководитель компании и его заместители). Регулярные совещания 1-2 раза в месяц. Определяет стратегию, ресурсы, принимает основные решения.
- Рабочий комитет (менеджеры высокого уровня). Совещания - раз в неделю. Вырабатывает политику, предлагает решения наиболее важных проблем, отслеживает результаты. Координатор команд (в малых фирмах не нужен). Решает вопросы, требующие согласования позиций групп.
- Рабочая команда по внедрению (6-7 специалистов из разных областей). Разбивается на логические группы по подразделениям, производственным направлениям и программам. Осуществляет контроль на уровне фирмы и ее отделов. Члены команд могут работать над отдельными задачами.
Важнейшая цель организации проекта - вовлечение сотрудников компании-клиента в процесс внедрения. Это достигается через распределение ответственности. Персонал отвечает за автоматизацию своих участков.
Оптимальная структура рабочей команды:
- сотрудник (сотрудники) заказчика, работающие на данном участке. Задачи: консультировать ИТ специалистов, осуществлять текущий контроль и предварительную приемку внедряемых объектов (формы, документы, отчеты и т. д.);
- сотрудник (сотрудники) отдела информационных технологий (ОИТ) заказчика. Задачи: освоить в необходимом объеме инструментальные средства исполнителя ("1С", "Галактика", Scala, R3 и др.), участвовать в доводке и разработке автоматизированной системы, служить информационным "буфером" между сотрудниками клиента и консультантами исполнителя;
- консультанты-программисты исполнителя. Задачи: разработать, внедрить, адаптировать необходимые модули, консультировать сотрудников ОИТ заказчика.
Использование в разработке и внедрении сотрудников ОИТ компании-клиента - не просто важный, а необходимый шаг. От него во многом зависит успех автоматизации.
Причины:
- сотрудники ОИТ так или иначе уже проводили автоматизацию своего предприятия и обладают ценным "know-how", которым на уровне диалога делиться, скорее всего, не станут;
- действительно хорошо освоить систему сотрудники могут, принимая непосредственное участие в ее разработке или настройке. В противном случае они останутся только продвинутыми пользователями и окажутся в неблагодарной роли передаточного звена между заказчиком и исполнителем.
Многие компании проводят успешную автоматизацию сравнительно крупных предприятий, привлекая к проекту не больше двух-трех своих консультантов. При этом ИТ-специалисты заказчика проходят предварительное обучение и могут выполнить основной объем работ на этапе настройки (кодирования). Консультантам остается осуществлять "чуткое руководство" (что тоже весьма непросто) и разбираться с тонкостями и сложностями процесса.
Если ИТ-специалисты заказчика к внедрению не привлекаются, стоит заключить долговременный договор на сопровождение и доработку системы.
Выработка целей
Выработка целей предусматривает четкое определение и описание качественных и количественных ожидаемых результатов проекта. Это краткая формулировка эффекта, который руководители надеются получить от вложения средств в автоматизацию.
Как уже говорилось, расчет ROI (коэффициент эффективности инвестиций) для проектов по автоматизации вызывает значительные трудности даже в наиболее "продвинутых" странах. Цели не определяются с точки зрения чисто финансовой выгоды, а связываются с появлением новых источников информации или получением качественного экономического эффекта.
Например, данные управленческого учета, необходимые руководителям для принятия решений, могут "пылиться" где-нибудь в экономическом отделе, который раз в квартал будет "на коленках" составлять никому не нужную отчетность. При этом создание автоматизированного хранилища не финансируется. Причина: нужная информация уже есть, и целый отдел с ней "работает".
Данные, как товар, не должны просто лежать где-то в компании. Их надо довести до конечных пользователей, причем желательно - пока данные свежие.
К счастью, большинство российских компаний уже осознали, что информация является одним из основных ресурсов предприятия, и рассматривают ее как важнейший элемент стратегического развития.
Продолжение в следующем выпуске.
