По методике «План Уайта»
| № | Наименование этапа | Цель, задачи этапа | Результаты Этапа |
| 1. | Предпроектное обследование | Исследование предприятия-клиента, сбор детальной информации о структуре и организации деятельности предприятия-клиента, систематизация и анализ полученных данных. | Результатом являются следующие документы: схема бизнес-процессов «as is »; схема бизнес-процессов «tо be »; бизнес-план реорганизации; краткосрочный план действий |
Окончание табл.4.4
| № | Наименование этапа | Цель, задачи этапа | Результаты Этапа |
| 2. | Предварительная переподготовка | Пояснить высшему руководству компании, в которой внедряется ИТ, что представляет собой процесс внедрения, добиться единого понимания процесса разными сотрудниками компании. | В результате руководители должны согласовать и прийти к единому видению результатов и ресурсов, необходимых в проекте. |
| 3. | Техническое задание | Разработать набор документов и спецификаций, определяющих требования к информационной системе. | Документ, в котором отражены вышеперечисленные требования к информационной системе и ее функциональности. |
| 4. | Технико-экономическое обоснование | Обосновать необходимость внедрения информационной системы и/или технологии в компании. | Качественные показатели и количественные оценки ТЭО. |
| 5. | Организация проекта | Вовлечение сотрудников компании-клиента в процесс внедрения. | Успешное внедрение и возможность консультирования силами ИТ-отдела компании-заказчика. |
| 6. | Выработка целей | Выработка целей проекта. | Четко сформулированные, согласованные и доведенные до всех участников структурированные задачи. |
Со временем компании все больше приходят к тому выводу, что проведение начального цикла необходимо (как, впрочем, и его оплата) независимо от того – к каким результатам и выводам приведет это обследование. По всей видимости, на такое решение влияет опыт других компаний и выводы, дающие основание понять, что без детального обоснования качественного внедрения ИТ быть не может.
Предпроектное обследование. Предварительное обследование сейчас проводят практически все ИТ-компании. Предпроектное обследование охватывает следующие задачи:
‑ исследование предприятия-клиента,
‑ сбор детальной информации о структуре и организации деятельности предприятия-клиента,
‑ систематизация и анализ полученных данных.
С помощью специальных средств (например, BPWin) строится диаграмма бизнес-процессов.
На базе анализа строятся модели «as is» (как есть) и «tо be» (как должно быть). Реорганизация реализует переход от одной модели к другой.
Результатом предпроектного обследования являются следующие документы:
‑ схема бизнес-процессов «as is»;
‑ схема бизнес-процессов «tо be»;
‑ бизнес-план реорганизации;
‑ краткосрочный план действий.
Практически всегда руководство компании-заказчика просит выявить приблизительную длительность и стоимость проекта.
Предварительная переподготовка. Цель — пояснить высшему руководству компании, в которой внедряется ИТ, что представляет собой процесс внедрения. На этом этапе необходимо добиться единого понимания процесса разными сотрудниками компании. В результате руководители должны согласовать и прийти к единому видению результатов и ресурсов, необходимых в проекте.
Зачастую, этому этапу уделяется недостаточно внимания со стороны компаний-внедренцев.
Нередко процесс обследования может быть воспринят персоналом компании «в штыки». Это следует понимать руководителю предприятия. Здесь существует несколько причин. Во-первых, персоналу придется участвовать в процессе внедрения и отвлекаться от повседневной работы, выполнение которой обязательно для сотрудников. Во-вторых, произойдет ломка взаимоотношений в команде, которые, несомненно, являются капиталом сотрудников. В-третьих, работники оправданно будут считать, что с внедрением информационной системы станет общим достоянием их информация. Например, наработанные годами контакты менеджеров по продажам и т. д.
Техническое задание. Техническое задание (ТЗ) — набор документов и спецификаций, которые определяют требования к информационной системе и ее функциональности. Техническое задание включает:
‑ требования к составу и структуре автоматизированных рабочих мест;
‑ разработку структуры, состава и топологии локальной вычислительной сети (ЛВС);
‑ разработку требований к программным средствам;
‑ требования к защите информации.
Процессы системы делятся на:
‑ процессы реального времени;
‑ диалоговые процессы;
‑ пакетные (в основном, сбор статистики, формирование отчетности за период, и др.);
‑ ручные (которые регламентируются, но их нет необходимости автоматизировать).
Для автоматизированных процессов конкретизируются требования к виду и форме документов.
В составлении ТЗ принимают участие ИТ-специалисты, в частности разработчики, которые обладают необходимым опытом и знаниями. Результатом является сформированный документ, в котором отражены вышеперечисленные требования к информационной системе и ее функциональности. После того, как составлено техническое задание представляется возможным оценить сроки и стоимость проекта.
Считается, что формирование ТЗ — работа заказчика, но практически всегда разработкой ТЗ (в силу наличия знаний, опыта, наработок) занимается фирма, осуществляющая внедрение.
Технико-экономическое обоснование (ТЭО). Технико-экономическое обоснование (анализ «затраты-эффект») позволяет обосновать необходимость внедрения информационной системы и / или технологии и на основе анализа принимать обоснованные решения и подтверждать финансовую необходимость изменений.
Считается, что для систем MRP/ERP при проведении технико-экономического обоснования наиболее показательными являются оценки по модулям логистика и управление запасами.
Внедрение системы позволяет существенно уменьшить запасы на складах. Это влечет за собой повышение оборачиваемости активов, которые ранее были «заморожены» в запасах. Также в результате внедрения сокращается цикл производства, исчезает дефицит товаров и т. д. Эти преимущества можно выразить в количественных оценках (например, стоимость помещений, перевозки и т. д.).
Обоснование необходимости автоматизации взаиморасчетов (поставщики, потребители, дебиторы, кредиторы и т. д.) очевидно. Здесь возможно привести следующие доводы:
‑ существенно снижается вероятность ошибки (особенно если существуют многовалютные расчеты);
‑ появляется возможность доступа у руководства компании к полной информации о положении дел для оперативного принятия решения;
‑ появляется возможность своевременно (on line) отслеживать должников и принимать меры.
Но, к сожалению, чтобы количественно оценить потери от всевозможных ошибок (например, при вводе первичной информации), следует заранее получить исчерпывающую информацию о финансовой истории клиента, что практически невозможно до подписания договора.
Организация проекта. Описание уровней организации проекта, участников и их задач приведены в табл. 4.5.
Таблица 4.5
Уровни организации проекта согласно методике «План Уайта»
| № | Уровень | Участники | Периодичность совещаний | Задачи |
| 1. | Управляющий комитет | руководитель компании, заместители | Регулярные совещания 1-2 раза в месяц | Формирует стратегию, ресурсы, принимает базовые решения |
| 2. | Рабочий комитет | менеджеры высокого уровня | Совещания — 1 раз в неделю | Разрабатывает политику, решения наиболее значимых задач, отслеживает и контролирует результаты. Координатор команд решает вопросы по согласованию позиций групп |
| 3. | Рабочая команда по внедрению | 6-7 специалистов из разных областей | Действует постоянно | Разбивается на функциональные группы по подразделениям, направлениям и программам. Реализует контроль на уровне компании и отделов |
Критически значимая цель организации проекта — привлечение сотрудников компании-клиента к процессу внедрения системы. Это может быть реализовано за счет распределения ответственности. Персонал отвечает за автоматизацию своих участков в проекте.
Для крупных компаний существуют три уровня организации проекта, Это управляющий комитет, рабочий комитет и рабочая команда по внедрению.
Оптимальная структура рабочей команды приведена в табл. 4.6.
Необходимо задействовать в разработке и внедрении сотрудников ИТ подразделения компании-клиента. Это обусловлено тем, что, во-первых, сотрудники ИТ подразделения компании-клиента уже участвовали в процессе автоматизации своей компании. В силу этого обстоятельства они могут обладать ценным «knоw-hоw». При разработке могут внести ценные и дельные замечания и подсказки.
Таблица 4.6
Структура рабочей команды согласно методике «План Уайта»
| № | Участники рабочей команды | Задачи |
| 1. | Сотрудники заказчика, работающие на данном участке | Консультирование ИТ специалистов, осуществление текущего контроля, предварительная приемка (анализ форм, документов, отчетов и т. д.) |
| 2. | Сотрудник (сотрудники) отдела информационных технологий (ИТ) заказчика | Изучение и освоение в необходимом объеме инструментальных средств исполнителя («1С», Scala, R3 и др.), участие в доработке и адаптации информационной системы, (информационный «буфер» между сотрудниками клиента и консультантами исполнителя) |
| 3. | Консультанты-программисты исполнителя | Разработка, внедрение, настройка, адаптация модулей ИС, консультирование сотрудников ИТ отдела заказчика |
Во-вторых, только непосредственно участвуя в разработке и / или настройке системы, сотрудники смогут достаточно хорошо изучить систему. В дальнейшем это позволит им давать консультации сотрудникам других отделов своей компании без привлечения организации-внедренца. В противном случае сотрудники ИТ-отдела останутся только продвинутыми пользователями внедряемой системы и смогут лишь передавать информацию между заказчиком и исполнителем. Самостоятельные консультации будут им не под силу.
Некоторые компании–внедренцы ИТ проводят успешную автоматизацию довольно крупных предприятий, с помощью двух-трех консультантов. В этом случае ИТ-специалисты заказчика проходят специальное предварительное обучение и далее выполняют практически весь объем работ на этапе настройки (кодирования). Если же специалисты ИТ- отдела заказчика не задействованы в процессе внедрения, то далее при функционировании информационной системы необходимы (обязательно потребуются) консультации компании-внедренца. Следовательно, необходимо заключить долговременный договор на сопровождение системы.
Выработка целей. Выработка целей — это четкое определение и описание качественных и количественных ожидаемых результатов проекта.
Не все показатели можно оценить количественно. Не все результаты определяются только с точки зрения финансовой выгоды. Они могут связываться с получением качественного экономического эффекта, так называемого качественного эффекта в сфере управления, с появлением новых источников информации.
Можно заметить, что большинство российских компаний уже осознали, что информация — один из базовых ресурсов компании, и рассматривают ее в качестве важнейшего элемента стратегического развития предприятия.
«Клиент готов». Если руководство компании клиента ознакомлено с деталями проекта, четко понимает цели проекта и готово активно участвовать в будущем проекте. Если общая схема бизнес-процессов описана, проведен детальный анализ существующего положения дел в компании, договор утвержден, а персонал не принимает будущие перемены «в штыки», то «клиент готов». В этом случае возможно переходить ко второй фазе автоматизации. Она состоит из одиннадцати этапов. Это технический проект, начальная переподготовка, планирование, управление данными, параллельное внедрение, выбор системы, ввод в эксплуатацию, этапы развития функциональности, оценка результатов, анализ текущего состояния, постоянная переподготовка.
Детальная характеристика этапов второй фазы автоматизации приведена в табл. 4.7.
Таблица 4.7