Руководство по организации работ при внедрении

В данной статье мы постараемся встать на место Руководителя проекта внедрения ERP системы на предприятии. Мы пройдем по 4 основным шагам, которые ему обычно приходится пройти, чтобы идея внедрения 1С:ERP 2 не осталась только идеей, а дошла до реализации. Надеемся, что данная «инструкция» для Руководителя проекта 1С:ERP Управление предприятием 2 поможет оптимально выстроить процесс внедрения и добиться положительного результата.

Определить цели и задачи проекта внедрения 1С:ERP — шаг 1

Первое, что необходимо понять, зачем мы решили инициировать сложный проект внедрения 1С:ERP 2, чего мы пытаемся добиться?

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

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

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

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

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

Определить ресурсы для проекта 1С:ERP 2 — шаг 2 

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

Рассмотрим пример списка ролей состава Исполнителей для средней команды проекта внедрения 1С:ERP 2 (на 150-200 пользователей системы):

1. Руководитель проекта

2. Консультант-аналитик 1С:ERP 2 (блоки Управление продажами, Управление закупками, Управление складом, Управление производством)

3. Консультант-аналитик 1С:ERP 2 (блок Регламентированный учет)

4. Консультант-аналитик 1С:ERP 2 (блок Кадровый учет и расчет заработной платы)

5. Консультант-аналитик 1С:ERP 2 (блок Бюджетирование)

6. Архитектор системы

7. Разработчик 1С (доработки функциональных блоков 1С:ERP 2)

8. Разработчик 1С (доработки функциональных блоков 1С:ERP 2)

9. Разработчик 1С (разработка средств первоначальной загрузки данных и интеграции)

10. Эксперт 1С, специалист по оптимизации системы

Тут следует понимать, что это состав ролей, а не конкретных людей-исполнителей. Часто бывает ситуация, что конкретный специалист может покрывать не обязательно одну, а несколько ролей (например, консультант-аналитик по блоку «Регламентированный учет» может так же быть консультантом-аналитиком по блоку «Бюджетирование», или Руководитель проекта может так же выполнять роль и Архитектора системы), часть специалистов могут быть загружены в проекте не на 100% (например, редко, когда требуется загрузка в режиме 100% Эксперта 1С на время всего проекта). Но практика показывает, что в любом случае, команда среднего проекта внедрения 1С:ERP Управление предприятием 2 должна состоять из приблизительно 5-6 человек (1 Руководитель проекта, 2 консультанта-аналитика 1С:ERP 2, 2-3 разработчика). И возникает вопрос, где взять данных специалистов?

Есть несколько вариантов решения проблемы:

1. Попытаться нанять недостающих специалистов на рынке труда.

Задача эта сложная, но многие ее недооценивают. Тем не менее, как показывает практика, общее время формирования «с нуля» (ну или почти «с нуля») проектной команды из 5-6 человек под проект 1С:ERP 2 занимает не меньше 6 месяцев. Кроме того, важно понимать, что на рынке труда свободных ресурсов, обладающих опытом и знаниями в проектировании и внедрении системы 1С:ERP 2 (особенно это касается руководителей проектов, архитекторов, консультантов-аналитиков, хорошо знающих систему и обладающих проектным опытом) почти нет и чтобы сформировать необходимую команду HR службе предприятия придется сильно постараться и, как показывает практика, далеко не у всех это получается.

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

Тут потенциальному Заказчику надо очень внимательно подойди к выбору Исполнителя. Необходимо понимать, что проекты делают, прежде всего, люди, а значит и надо постараться оценить компетенции компании-подрядчика и ее кадровых ресурсов с точки зрения наличия необходимого проектного опыта, навыков и компетенций. Подробнее данную тему мы рассмотрели в нашей статье «Внедрение 1С:ERP 2. Ошибки выбора Подрядчика»

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

Руководителю проекта со стороны Заказчика надо оценить степень загрузки уже имеющихся 1с специалистов: сколько процентов времени они смогут уделять будущему проекту. Очень часто получается ситуация, что у компании есть свои 1с специалисты, но они достаточно сильно загружены, и у них нет времени заниматься новым проектом внедрения 1С ERP 2. Кроме того, очень важно понять, обладают ли штатные программисты достаточным опытом для внедрения таких систем, как ERP (доработка, проектирование, запуск системы 1С:ERP 2). Часто такого проектного опыта и компетенций у них нет.

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

• время на обучение (и, желательно, сертификацию) — изучение функциональных блоков конфигурации 1С ERP 2 (а это не быстрый процесс, на него надо закладывать не меньше 3-6 мес.)

• опытный наставник (или руководитель) – иначе команда, составленная из неопытных в проектах внедрения 1С ERP 2 специалистов, рискует в процессе внедрения «наступить на все возможные грабли» и потратить в разы больше времени и ресурсов, чем опытный коллектив разработчиков

 4.       Различные «гибридные варианты» наполнения проекта ресурсами. Частично нанять Подрядчика, частично привлечь свои ресурсы, частично нанять специалистов на рынке труда.

Иногда «гибридные варианты» формирования проектных команд дают неплохие результаты, но тут так же есть достаточно серьезные риски, особенно если планируется использовать свои ресурсы и ресурсы Подрядчика. Прежде всего Руководителю проекта внедрения 1С:ERP Управление предприятием 2 надо ответить на следующие вопросы:

• Кто будет осуществлять управления ресурсами? Внутренний Руководитель проекта или Подрядчик. Из нашей практики особенно часто «не взлетает» вариант, когда Руководителю проекта и Архитектору Подрядчика поручают управлять ресурсами Заказчика (программистами и консультантами). Часто, у представителей Подрядчика просто нет полномочий и возможности полноценно управлять программистами и консультантами Заказчика: нет возможности их поощрять и наказывать, нет возможности полноценно контролировать их работу – добиваться результата в условиях отсутствия инструментов контроля и управления часто становится почти не возможным

• Как будут распределены риски и зоны ответственности между Подрядчиком и Исполнителем? Это достаточно сложный вопрос, особенно, если не удается разбить проект внедрения ERP системы на предприятии на взаимозависимые логические блоки: специалисты «смешанной» проектной команды в итоге занимаются всем проектом и как в такой ситуации понять, где заканчивается ответственность Подрядчика и начинается ответственность Заказчика часто совершенно не очевидно.

Выбор технологии проекта внедрения 1С:ERP — шаг 3

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

Бывают ситуации, когда Руководителю проекта 1С:ERP близок подход Agile, но сама компания и высшее руководство компании оказываются совершенно не готовыми к работе по такой методике: ключевым бизнес-заказчикам нужны Технические задания, фиксированные сроки, фиксированная стоимость проекта, а это уже идет в разрез с методологией Agile. Либо сама компания из-за масштаба и высокой степени инертности просто оказывается не готова к ведению проекта по гибким технологиям: решения принимаются достаточно долго, с прохождением через сложную иерархическую структуру, а это часто не приемлемо для Agile/Scrum.

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

• Этап 1. Проектирование и моделирование системы, формирование «Целевых моделей».

• Этап 2. Разработка и внедрение системы по итеративной технологии Agile

На первом этапе мы проводим обследование, а затем выполняем работы по проектированию системы в методологии «как будет»: выявляем функциональные разрывы между возможностями 1C ERP 2 и бизнес-процессами Заказчика и принимаем концептуальные решения о реализации необходимых механизмов, средств интеграции и доработок.

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

Кроме того, мы формируем для себя Журнал задач проекта (Project backlog) с предварительными рамочными оценками сроков и стоимости задач по доработкам. Сформированный backlog позволит в будущем при разработке и внедрения системы ликвидировать простои проектной команды и постоянно брать задачи из данного backlog к реализации. Это увеличит темпы проекта.

На этапе реализации системы мы обычно применяем итеративную технологию по принципам Agile. Суть данной технологии в итерационном процессе реализации требований Заказчика к информационной системе. После моделирования и проектирования (Этап 1) определяется Журнал задач проекта (Project backlog), далее запускается итеративный процесс реализации задач проекта из Project backlog, демонстрации результатов и внесения корректировок. В ходе итераций могут выполняться работы по уточнению Целевых моделей, доработкам системы, реализации средств интеграции и средств загрузки первоначальных данных, обучению и консультированию пользователей, поддержки опытной эксплуатации функциональных блоков системы.

Сформировать план и бюджет проекта 1С: ERP на предприятии — шаг 4

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

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

Кроме того, очень важна поддержка проекта внедрения ERP системы на предприятии со стороны высшего руководства и собственников компании. Часто без такой поддержки проект очень сложно реализовать, ведь пользователями и потребителями информации системы 1С:ERP 2 становятся почти все подразделения и отделы компании. Достаточно часто интересы и цели отделов и подразделений компании могут вступать в некоторые локальные противоречия друг с другом и для успешного продвижения проекта нужны серьезные «управляющие воздействия» сверху.

Подробнее про основные проблемы проектов можно прочитать в нашей статье «Топ 5 проблем проектов внедрения 1С:ERP 2, которые не учитывают Заказчики».

Заключение для руководителя проекта внедрения 1С:ERP 

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

В заключение, хотелось бы добавить, что по нашему мнению – 90% процентов успеха проекта, это выстраивание правильной коммуникации между ИТ-специалистами и бизнес-заказчиками, и задача выстраивания этой коммуникации ложится, прежде всего, на плечи Руководителя проекта внедрения 1С:ERP на предприятии. Задача эта не простая, но именно достижение согласия и взаимопонимания между исполнителями проекта, ключевыми пользователями, владельцами/руководителями бизнеса как раз и позволяет делать проекты внедрения систем 1С:ERP 2 успешными и эффективными.

Читайте также:

Похожие статьи:

ВНЕДРЕНИЕ ИЗМЕНЕНИЙ: 8 ЭТАПОВ

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

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

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

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

1. Проблематизация ситуации — вовлечене сотрудников;
2. Формирование команды реформаторов;
3. Формулирование Целей;
4. Пропаганда изменений;
5. Создание условий, устранение препятствий;
6. Достижение быстрых результатов;
7. Анализ и корректировка;
8. Закрепление и расширение преобразований.

ВНЕДРЕНИЕ ИЗМЕНЕНИЙ: ЭТАП 1 — ПРОБЛЕМАТИЗАЦИЯ И ВОВЛЕЧЕНИЕ

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

В 90% случаев руководитель недооценивает трудность задачи и считает, что достаточно лишь объявить о том, что вводятся изменения. Но сотрудники привыкли жить «по-старому» и почти всегда не готовы к переменам.

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

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

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

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

Главные ловушки на этом этапе:

1. преобладание пассивного менеджмента и недостаток руководителей-Лидеров
2. паралич действий из-за осознания возможных рисков от внедрения реформ

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

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

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

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

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

###

ВНЕДРЕНИЕ ИЗМЕНЕНИЙ: ЭТАП 2 — КОМАНДА РЕФОРМАТОРОВ

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

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

Для малого предприятия команда реформаторов может состоять из 3-5-ти сотрудников. Для крупной компании численность может достигать 20-50 сотрудников. Костяк группы это всегда ТОП-менеджеры.

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

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

Стандартные ловушки этого этапа:

1. Отсутствие в команде реформаторов Руководителя предприятия
2. Малочисленность группы
3. Отсутствие в группе лидеров мнений
4. Передача управления группой линейному представителю, а не ТОП-руководителю предприятия

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

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

ВНЕДРЕНИЕ ИЗМЕНЕНИЙ: ЭТАП 3 — ФОРМУЛИРОВАНИЕ ЦЕЛЕЙ

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

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

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

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

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

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

ВНЕДРЕНИЕ ИЗМЕНЕНИЙ: ЭТАП 4 — ПРОПАГАНДА

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

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

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

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

Вы можете делать новостную рассылку, вести чат группы реформаторов в CRM или в вотсап — все это поможет показать коллективу, что движение и положительные результаты есть!

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

ВНЕДРЕНИЕ ИЗМЕНЕНИЙ: ЭТАП 5 — УСТРАНЕНИЕ ПРЕПЯТСТВИЙ

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

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

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

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

ВНЕДРЕНИЕ ИЗМЕНЕНИЙ: ЭТАП 6 — ДОСТИЖЕНИЕ БЫСТРЫХ РЕЗУЛЬТАТОВ

Почему большинство преобразований тормозятся или останавливаются вовсе? Люди устают, теряют импульс, вдохновение и веру в получение результата.

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

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

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

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

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

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

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

ВНЕДРЕНИЕ ИЗМЕНЕНИЙ: ЭТАП 7 — АНАЛИЗ И КОРРЕКТИРОВКА

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

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

ВНЕДРЕНИЕ ИЗМЕНЕНИЙ: ЭТАП 8 — ЗАКРЕПЛЕНИЕ И МАСШТАБИРОВАНИЕ

На этом этапе вы завершаете внедрение изменений: у вас есть полученный результат, вы достигли своих целей.

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

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

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

ВНЕДРЕНИЕ ИЗМЕНЕНИЙ: ЭМОЦИОНАЛЬНОЕ СОСТОЯНИЕ СОТРУДНИКОВ

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

Ниже представлен график изменений эмоционального состояния работника в процессе внедрения изменений:

На этапе 1 работник проваливается в яму негатива и шока — новое не привлекает, а скорее пугает и настораживает.

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

На этапе 3 работник признает свое неумение и некомпетентность, но понимания, веры и, главное, понимания как именно развить в себе новые навыки еще нет.

На этапе 4 работник тотально признает реальность и то, что «отвертеться» от перемен не получится. Он приступает к тестированию нового, и это этап 5: здесь растет раздражение, т.к. еще очень плохо получается делать что-то по-новому, понимания пользы от нового все еще нет.

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

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

Мы рассказали вам о закономерностях внедрения изменений. Используйте алгоритм для управления изменениями в своей компании.

Отвечая на столь обширный вопрос в рамках небольшого текста, мы берем на себя такую же абсурдную задачу, как в случае с авторами книг «Фейербах за 2 минуты» или «коучами» на психологических тренингах «Как добиться всего, сидя на диване». Тема очень сложная и как следует изучить ее, можно лишь прочитав не одну книгу, хорошо бы и попрактиковаться. По этой причине, для очистки совести, сразу же поговорим об источниках информации, где можно найти больше сведений по интересующему вас вопросу. Кроме российских периодических изданий, есть много иностранных, мало известных в России: Quality Progress, Journal for Quality Technology, Quality Management Journal. Если говорить об учебниках, то при выборе конкретной книги стоит учитывать, что лишь очень немногие публикации по качеству в России могут похвалиться детализацией, достаточной для овладения темой на практическом уровне. Многие издания не учат внедрять систему менеджмента, а скорее описывают то, как это должно выглядеть. Еще один важный источник информации по теме – руководства Международной организации по стандартизации (International Organization for Standardization, – ред.). Так сложилось, что именно по стандарту ISO 9001 «Системы менеджмента качества. Требования» в нашей стране обычно сначала внедряют, а затем сертифицируют свою СМК (систему менеджмента качества, – ред.). Руководств поясняющих и комментирующих текст стандарта – много, но особо хочется отметить «Руководство по концепции и использованию процессного подхода для систем менеджмента». В этом тексте раскрываются детали процессного подхода, с которыми у внедряющих ISO 9001 организаций возникает наибольшее количество трудностей.

Что касается внедрения, то в самом общем виде оно выглядит следующим образом. Сначала высшее руководство принимает решение о необходимости имплементации системы управления качеством. После этого формируется рабочая группа, которая и будет осуществлять внедрение. Численность и состав группы, о которой идет речь, может быть различной, в зависимости от многих параметров, прежде всего от размера самой компании. Если она небольшая – 10-20 человек, то бывает достаточно 1-2 сотрудников, включая представителя высшего руководства. Последнее – обязательное требование стандарта ISO 9001 в любом случае. В более крупных организациях задача создания системы управления качеством резко усложняется. Например, главный руководитель может не знать деталей и половины видов деятельности, которые проводятся в организации. И это еще не самое главное отличие. В таких случаях рабочая группа по внедрению может сильно разрастаться и включать в себя помимо сотрудников, которые ответственны за отдельные небольшие участки работы штатных и внештатных консультантов по качеству или менеджеров. Различные направления работы, связанные с внедрением СМК часто ложатся на сотрудников, как дополнительная ноша, помимо их основной занятости. Подключение специалистов по качеству оправдано тем, что профессионалы посвящают своему делу весь рабочий день и владеют своим предметом углубленно. Смысл создания сводного коллектива работников для целей внедрения СМК не следует понимать превратно. Чтобы система качества работала, необходимо, чтобы все сотрудники в той или иной степени были охвачены общей деятельностью, рабочая группа лишь станет двигателем преобразований и, если развивать автомобильные ассоциации, стартером.

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

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

Обучение является неотъемлемой частью внедрения системы управления качеством, однако, отнести его к какому-то этапу создания СМК не представляется возможным. Оно красной нитью проходит через весь процесс. Рабочая группа, которая будет внедрять систему сама должна овладеть большим количеством практических сведений по тому, как это делается. При внедрении документации СМК и далее, все сотрудники должны познакомиться с различными аспектами теории, которая им понадобится в работе. После того как система внедрена, периодически нужны новые учебные часы, чтобы осветить произошедшие изменения или ввести новые процедуры. Для обучения персонала и руководителей часто привлекают консультантов. Содержание тренингов и семинаров зависит от стадии запуска системы и статуса работника. Непосредственным исполнителям в первую очередь нужны знания о требованиях к продукции или услугам клиентов, руководителям разных степеней для составления пригодятся наработанные в менеджменте методики написания документации – матрицы, таблицы, существуют IT-комплексы для решения проблемы, близкие по масштабу бухгалтерской и складской «1C». Всем сотрудникам без исключения необходимы некоторые знания об их СМК в целом – для этого штудируют Руководство по качеству и владение положениями стандарта ISO 9001.

Очень важную роль для поддержания СМК, которая уже была создана, играют периодические внутренние аудиты, производимые руководством. Еще один обязательный инструмент из стандарта ISO 9001. Разумеется, чтобы несоответствия действительно удавалось устранять, нужно иметь максимально полное представление о ситуации, которое отчасти дают аудиты, а отчасти сама ротация документов. По результатам проверок и анализов должны быть предусмотрена система мотивации сотрудников исходя из их загруженности и успехов с точки зрения СМК. На то и волки, чтобы пастух не дремал, – говорит пословица. В качестве дополнительного теста работоспособности СМК может служить сертификация – третейская, независимая оценка.

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

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

Вам понравилась статья? Не хотите пропускать новые? Тогда подпишитесь на RSS или получайте новые статьи мгновенно на электронную почту

6.7.4. Работы при разработке технического задания на внедрение программного продукта

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

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

Методической поддержкой для подготовки технического задания является ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Техническое задание на создание автоматизированной системы», в котором определен перечень требований к содержанию документа и проведению испытаний.

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

1. общие сведения;
2. назначение и цели создания (развития) системы;
3. характеристика объектов автоматизации;
4. требования к системе;
5. состав и содержание работ по созданию системы;
6. порядок контроля и приемки системы;
7. требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
8. требования к документированию;
9. источники разработки.

Содержание перечисленных разделов подробно рассмотрено ранее.

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

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

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

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

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

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

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

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

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

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

6.7.6. Работы при определении границ проекта и плана внедрения

Основой подготовки устава проекта является стандарт ANSI PMI PMBOK® 3-rd Edition (2004) — основной стандарт, описывающий все процессы управления проектами.

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

Устав может включать в себя:

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

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

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

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

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

Стратегия внедрения определяет подход к внедрению программного продукта в организации. Существуют различные стратегии внедрения, используемые ведущими разработчиками программных продуктов. Например, при внедрении ERP-систем обычно применяют стратегии «Большого взрыва», «Шаг за шагом», пилотное внедрение.

Принцип «Большого взрыва» предполагает одновременное внедрение всех функциональных модулей программного продукта и замен старых систем.

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

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

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

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

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

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

6.7.7. Разработка документа «Дизайн системы»

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

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

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

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

Результатом проведенных работ является документ «Дизайн системы» и техническое задание на проведение необходимых доработок. В соответствии с техническим заданием организация — исполнитель работ дорабатывает функционал системы.

6.7.8. Управление процессом настройки программного продукта

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

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

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

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

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

6.7.9. Работы при управлении процессом создания пилотной версии информационной системы

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

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

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

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

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

6.7.10. Обучение персонала организации методологии внедрения и использования выбранного ИТ — решения

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

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

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

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

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

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

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

6.7.11. Организация опытной эксплуатации информационной системы и разработка методики испытаний

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

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

В соответствии с ГОСТ 34.603-92 «Информационная технология. Виды испытаний автоматизированных систем» для информационных систем устанавливаются следующие виды испытаний: предварительные, опытная эксплуатация, приемочные.

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

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

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

Документ «Программа и методика испытаний» включает:

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

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

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

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

6.7.12. Управление вводом информационной системы в промышленную эксплуатацию и разработка ее регламентов

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

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

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

В соответствии с ГОСТ 34.603-92 «Информационная технология. Виды испытаний автоматизированных систем» документ «Программа приемочных испытаний» содержит:

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

Приемочные испытания включают проверку:

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

6.7.13. Организация мониторинга результатов внедрения информационной системы и внесения необходимых модификаций

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

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