· Ввод реальных данных
· Переход на новую систему
Рассмотрим более детально каждую стадию.
Описание бизнес процессов.
Для того, чтобы иметь четкое представление о том, какие конкретно процессы будут подвергаться изменениям и каким образом при изменении информационной системы, нужно иметь четкое формальное описание существующих процессов. Детальность такого описания должна быть на уровне концепции процесса и основных его составляющих, а также входящих и выходящих ресурсов. Например, если это процесс обработки заказов, то нужно создать общее описание процесса (с чего начинается, из чего состоит и чем заканчивается, в какое время происходит какая стадия этого процесса, какие параметры существуют у заказов, например условия оплаты, классы заказчиков, категории услуг и продуктов, с каких складов осуществляются отгрузки и т.д.). Пример такой схемы приведен в Приложении 1 (Прием заказа). При описании бизнес процессов может оказаться полезным создание схем, потому что они наглядно показывают основные составляющие процесса.
Описание бизнес процессов является не только базой, по отношению к которой будет меняться процесс, но также описание процессов является неким механизмом оценки возможных изменений и критерием, которому должна соответствовать новая схема измененного бизнес - процесса.
Описание бизнес - процессов осуществляется в самом начале проекта, а результат этой стадии - наличие свежего сборника документации по процессам организации - является той информационной базой, с помощью которой формируется содержание изменений в ходе проекта.
Тренинги по новой системе (при необходимости).
Тренинги необходимы в случае, когда непосредственные участники проекта не знакомы с системой. Для того, чтобы у участников проекта сформировалось определенное представление о новой системе, приглашают специалистов (это могут быть как внешние консультанты, аудиторы или разработчики системы, так и сотрудники данной организации, например из другого филиала, где система уже установлена).
Следует отметить, что нет необходимости в прохождении детального тренинга, то есть такого тренинга, который даст полное представление о том, как система может работать в других организациях. Это объясняется уникальной спецификой бизнес - процессов каждой организации, обусловленной бизнес технологиями, спецификой региона или отрасли. Участники проекта могут прослушать курс по базовой функциональности системы с объяснением тех принципов настройки тех параметров (системных настроек), с помощью которых можно создать необходимую инфраструктуру для осуществления бизнес - процессов. Фактически это означает, что основной задачей участников проекта в дальнейшем будет моделирование бизнес процессов организации, причем оно должно быть основано на принципе удовлетворения необходимых потребностей организации, а не использования существующий возможностей системы.
Тестирование функциональности системы.
После прохождения тренинга участники проекта начинают тестировать систему. Фактически это означает начало моделирования процессов в системе, содержательным стержнем которого служит та документация, которая создавалась при описании бизнес - процессов. Происходит проверка возможности системы обрабатывать в себе ту информацию, которая циркулирует в организации. Это очень важный этап, потому что именно здесь закладывается основа того, что в дальнейшем будет называться системой данной организации. Все дальнейшие стадии будут напрямую зависеть от этой, а содержание этих стадий будет являться производной от того, что будет заложено на данном уровне. При тестировании системы создается документация по описанию функциональных возможностей системы, а также начинают формироваться методические материалы, описывающие, как в системе выглядит тот или иной процесс; в дальнейшем такая документация будет использоваться пользователями системы.
Также одним из ключевых моментов автору видится в том, что именно на данной стадии должны произойти все согласования с будущими пользователями системы и их менеджерами по приемлемости возможностей системы.
Необходимые доработки.
В случае, когда обнаруживается, что система не позволяет осуществлять какой-нибудь важный процесс (или в системе не существует необходимого приемлемого набора отчетности), формируются запросы на разработку дополнительной функциональности.
Разработка может осуществляться как внешними специалистами, так и внутренними. Данная стадия происходит как правило в параллели с предыдущей и иногда даже с последующей (например, когда доработки не носят существенного характера и не могут помешать обучению пользователей и дальнейшему тестированию системы).
На данной стадии может измениться содержание проекта, причем как в сторону сокращения части внедряемой функциональности, так и в сторону ее расширения, которое во многом это также зависит от бюджета проекта.
Обучение пользователей функциональности системы.
После того, как функциональность системы протестирована, необходимые доработки сделаны, наступает стадия, которая является прелюдией к шлифовке системы. Участники проекта начинают обучать пользователей работе с системой. Это необходимо не только для того, чтобы они смогли качественно протестировать систему и выдать свои рекомендации, но также и для того, чтобы они привыкли к системе и натренировались для дальнейшего эффективного включения в работу с новой системой (так называемый “training on the job”), а потенциально возможный негативный настрой растворился в изучении возможностей системы и предварительной работе с ней.
Тестирование системы пользователями.
Несмотря на то, что система тестировалась участниками проекта, как бы хорошо они не разбирались в процессах организации, у непосредственных участников рабочих процессов (будущих пользователей системы) развито гораздо более детальное представление об этих процессах. Пользователи могут знать достаточно различных “подводных камней”, которые выясняются только через определенное время и которые очень сложно учесть в описании процессов людям, которые не участвуют в процессах на регулярной ежедневной основе. Это объясняется еще и тем, что ситуация в бизнесе постоянно меняется, меняются с ней и бизнес - процессы, причем такие изменения могут быть как значительными, так и совершенно незаметными.
В ходе тестирования проверяется качество системы, ее полнота и готовность к внедрению. Здесь многое зависит от участников проекта. Под их ответственность особенно должно попасть следующее:
· разработка набора сценариев тестов для пользователей:
· тесты, проверяющие функциональность системы;
· тесты, проверяющие взаимодействие в системе между разными рабочими группами, что напрямую связано с циркуляцией информации по системе;
разработка сценариев должна производиться участниками проекта, потому что только они имеют так называемый вид сверху на процессы, причем более детальный, чем менеджеры рабочих групп, а пользователи как правило не имеют такого представления о процессах в целом, являясь экспертами в своей области;