скачать рефераты

МЕНЮ


Реорганизация бизнес-процессов при изменении информационной системы в крупной организации

p>Рассмотрим основные составляющие, которые следует включить в начальный план проекта:
. Описание объекта изменения (что необходимо изменить - систему, часть ее функциональности и т.д.);
. Краткая рекомендация по необходимости изменения (причина изменения, преимущества новой системы, описание целей, которых нужно достичь при завершении проекта);
. Основные стадии проекта (см. ниже);
. Основная функциональность новой или измененной системы (то есть список того, что войдет в проект) и сроки проведения изменений (если проект состоит из нескольких ступеней, результатом каждой из которых является изменение части функциональности системы, то здесь каждая ступень должна иметь четко поставленные сроки);
. Список участников проекта, их основных обязанностей и ролей (менеджер проекта, топ менеджмент, ресурсы, участники и т.д.);
. Бюджет проекта;
. Что не войдет в проект (это необходимо для внесения ясности в ожидания менеджеров рабочих групп относительно возможностей системы);
. Какие функциональные возможности системы нужно изучить в дальнейшем для потенциальной установки в дальнейшем (список);
. Риски (какие факторы могут помешать реализации проекта в полном объеме, в поставленные сроки с установленным бюджетом);
. Критерии успешного выполнения проекта
. Список необходимых условий, от которых зависит успешная реализация проекта.

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

Рис. 3.1. Планирование проекта по изменению информационной системы.

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

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


Рис. 3.2. “Сроки проекта - содержание проекта”

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

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

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

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

Тренинги по новой системе (при необходимости).
Тренинги необходимы в случае, когда непосредственные участники проекта не знакомы с системой. Для того, чтобы у участников проекта сформировалось определенное представление о новой системе, приглашают специалистов (это могут быть как внешние консультанты, аудиторы или разработчики системы, так и сотрудники данной организации, например из другого филиала, где система уже установлена).
Следует отметить, что нет необходимости в прохождении детального тренинга, то есть такого тренинга, который даст полное представление о том, как система может работать в других организациях. Это объясняется уникальной спецификой бизнес - процессов каждой организации, обусловленной бизнес технологиями, спецификой региона или отрасли. Участники проекта могут прослушать курс по базовой функциональности системы с объяснением тех принципов настройки тех параметров (системных настроек), с помощью которых можно создать необходимую инфраструктуру для осуществления бизнес - процессов. Фактически это означает, что основной задачей участников проекта в дальнейшем будет моделирование бизнес процессов организации, причем оно должно быть основано на принципе удовлетворения необходимых потребностей организации, а не использования существующий возможностей системы.

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

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

Обучение пользователей функциональности системы.
После того, как функциональность системы протестирована, необходимые доработки сделаны, наступает стадия, которая является прелюдией к шлифовке системы. Участники проекта начинают обучать пользователей работе с системой. Это необходимо не только для того, чтобы они смогли качественно протестировать систему и выдать свои рекомендации, но также и для того, чтобы они привыкли к системе и натренировались для дальнейшего эффективного включения в работу с новой системой (так называемый “training on the job”), а потенциально возможный негативный настрой растворился в изучении возможностей системы и предварительной работе с ней.

Тестирование системы пользователями.
Несмотря на то, что система тестировалась участниками проекта, как бы хорошо они не разбирались в процессах организации, у непосредственных участников рабочих процессов (будущих пользователей системы) развито гораздо более детальное представление об этих процессах. Пользователи могут знать достаточно различных “подводных камней”, которые выясняются только через определенное время и которые очень сложно учесть в описании процессов людям, которые не участвуют в процессах на регулярной ежедневной основе.
Это объясняется еще и тем, что ситуация в бизнесе постоянно меняется, меняются с ней и бизнес - процессы, причем такие изменения могут быть как значительными, так и совершенно незаметными.
В ходе тестирования проверяется качество системы, ее полнота и готовность к внедрению. Здесь многое зависит от участников проекта. Под их ответственность особенно должно попасть следующее:
. разработка набора сценариев тестов для пользователей:

. тесты, проверяющие функциональность системы;

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

Ввод реальных данных.
После того, как все необходимые детали по работе системы согласованы с пользователями, система признается готовой к установке, а топ менеджмент принимает окончательное решение о внедрении (так называемое “go-no-go solution”), начинается сам переход с одной системы на другую.
Этот переход начинается с ввода реальных данных в новую систему. Опыт показывает, что наиболее эффективным является начало ввода данных в параллели с вводом в старую систему (хотя возможен и вариант резкого перехода, но его рекомендуется проводить только когда переход на новую систему не представляет особой сложности, является стандартным хорошо изученным решением, с успехом применяемым ранее). Это требует дополнительного напряжения со стороны пользователей, потому что в течение какого-то времени ( день, неделя или даже больше) им придется работать в двух системах одновременно вместо одной. Привлекать людей со стороны не рекомендуется, потому что это дорого, для этих людей нужно провести хороший тренинг (несмотря на который вероятность ошибок все равно велика), что занимает время, которого в конце проекта становится катастрофически мало.
Ввод данных (все системные настройки должны быть уже введены в систему на стадии тестирования системы пользователями) начинается с ввода так называемых мастер - данных:
. заказчики, их адреса, контактные лица и т.д.;
. список продуктов с необходимыми характеристиками, такими, как количество штук в коробке, размеры, вес, коды и т.д.;
. цены и скидки - как на продукты (закупочные и продажные), так и на другие услуги (перевозки, консультации, денежные переводы и т.д.);
. склады, их адреса, контактные лица и т.д.;
. поставщики, их адреса, контактные лица и т.д.;
. другие партнеры (перевозчики, консультанты, банки и т.д.);
. транспорт, характеристики машин (объем, тип, номера и т.д.);
. другое.
Затем начиная с определенного момента, когда все базовые данные введены, в систему начинает вводиться рабочая информация, соответствующая бизнес - процессам.
Это начинается с ввода начальных балансов (количества продукции на складах, счета к оплате и счета к получению, кредитный статус заказчиков, открытые заказы и т.д.), как правило в выходные дни. Потом начиная со следующего рабочего дня начинается параллельный ввод данных в две системы - новую и старую.
Параллельный ввод данных длится до тех пор, пока в новую систему не поступит вся необходимая информация для начала самостоятельной (то есть без помощи данных в старой системе) работы - например, когда все не отгруженные заказы, которые существовали в старой системе, были или введены в новую, или отгружены в старой системе и попали в архив.

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

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

Страницы: 1, 2, 3


Copyright © 2012 г.
При использовании материалов - ссылка на сайт обязательна.