Виды деятельности процесса внедрения ис. Информационная система
У меня есть многолетний опыт внедрения и последующего сопровождения информационных систем на различных предприятиях. Опыт, в большинстве случаев, был успешным – но здесь я хочу побеседовать, в первую очередь, о причинах, ведущих к неудаче в этом деле, предостеречь вас от возможных ошибок. Я означу собственный метод внедрения, который я использовал неоднократно и который помогает избежать большинства из них.
Первая и самая главная причина провала: некорректно поставленная цель для информационной системы .
Это один из основных вопросов для любого проекта вообще. Заказчик зачастую выбирает цель, которая не имеет к информационной системе никакого отношения, или же зависит от нее незначительно. Примеры: увеличение продаж, занятие большей доли рынка, создание другой культуры управления предприятием и т. д. Но если компания производит товар, спрос на который падает – как тут поможет информационная система? Проблему здесь должно решать подразделение маркетинга. Если нужно изменить культуру предприятия – это вопрос управления персоналом и генерального директора. У некоторых, однако, теплится надежда, что стоит отдать деньги за информационную систему - и проблемы, связанные с организаций бизнеса, решатся сами собой. Обещания продавцов, «впаривающих» дорогие, иностранного производства, многократно проверенные и построенные на «лучших мировых бизнес-практиках» системы лишь укрепляют эту веру. Но на деле компания с неэффективным стилем управления останется неэффективной, только уже с информационной системой. Если на вашу продукцию упал спрос, он тоже не изменится никак. Правда, информационная система позволит вам быстро и точно подсчитать убытки, в том числе и от ее внедрения.
Корректно поставленная цель внедрения информационной системы - залог успеха этого внедрения. Правильны цели, связанные с обработкой информации: хранение, поиск данных, задачи, связанные с расчетами, группировкой, анализом. При внедрении системы все это требовать меньше времени. Помните, однако, что ускорение неудачных процессов приведет к еще более неудачному результату для компании, чем было бы без системы.
Вот один из недавних случаев на переговорах с заказчиком. Заказчик хочет сменить систему конфигурирования изделия, надеясь, что это упорядочит работу производства. С его слов, новая система должна предоставить только ограниченный выбор доступных опций изделий. Тогда производству и отделу согласования будет проще работать, появится набор стандартных решений. У заказчика, однако, уже есть конфигуратор. Сразу возник вопрос: зачем менять? Ответ потрясающий: другой конфигуратор «заставит нас работать правильно», создать необходимую документацию на изделие, изменить схемы обработки заказов и скорректировать культуру работы с заказчиком. Получается, менеджеры понимают, в чем проблема, но расписываются в собственном бессилии изменить ситуацию и перекладывают трудности по реорганизации бизнес-процессов на подразделение, которое за это не отвечает. Как правило, такой проект завершается крахом или затягивается на долгие годы.
Даже если предположить, что специалисты-информационщики знают, как следует изменить бизнес-процессы (с логикой у нас порядок), у них все равно нет нужного административного ресурса, да и ожидаемый результат зависит, в первую очередь, не от программного обеспечения. Здесь явно путается следствие и причина. Допустим, есть предприятие А с информационной системой ABC. Предприятие работает стабильно, нет авралов, неразберихи, заказы выполняются в срок, есть планомерная деятельность отлаженного механизма. Можно сделать вывод, что все хорошо благодаря системе ABC, но это 100% не так. Наличие системы ABC у предприятия A, кончено же, вносит свой вклад в бизнес, но не является ключевым. Если руководство некоего предприятия Б решило внедрить у себя систему ABC в надежде, что после ее внедрения предприятие Б тоже будет работать так же, как A, его ждет сюрприз. Деньги будут потрачены, но ожидаемый эффект не наступит, т.к. методика работы на предприятии Б не изменится.
Эффективные цели
Повторюсь – цели, которые я считаю эффективными при внедрении информационной системы, связаны с ускорением существующих бизнес-процессов или созданием новых для обработки данных. Не стоит перекладывать на информационную систему задачи других подразделений, особенно без права влиять на эти процессы.
Внедрение информационной системы позволяет запустить бизнес-процессы, которые прежде не имели права на существование из-за неприемлемых сроков выполнения. Более того, я считаю, что запуск новых бизнес-процессов - обязательное условие для успешного внедрения системы. Очевидно, если раньше мы использовали напильник для выполнения работ, а теперь у нас станок, это будет другой процесс. Если планирование было налажено плохо, станок, из-за своей производительности, принесет компании еще больший убыток.
Итак, с целями мы определились, теперь осталось правильно составить техническое задание.
Техническое задание
Это вторая по важности составляющая успеха при внедрении информационной системы. Напомню, эффективная цель – ускорение бизнес процессов, которых может быть еще не существует. Заказчик только в общих чертах понимает, что ему нужно. Хорошим вариантом считается уже на первых этапах работы составить подробное многостраничное ТЗ. Это работает, особенно для исполнителя по контракту. Заказчик все подписывает, не до конца понимая, что именно сделает исполнитель. А между тем, за каждое новое поле или форму, не записанные в ТЗ, исполнитель запросто попросит с заказчика еще денег. В итоге заказчик получит процесс с неполными или избыточными данными, хотя формально контракт был выполнен в точном соответствии с требованием. Заказчик будет недоволен и во второй раз к этому исполнителю не обратится.
Получается, что не заказчик подписал неподходящее ТЗ, а исполнитель разработал и предложил совсем не то – не угадал, о чем мечтал заказчик. Замечаете парадокс? Исполнитель сам для себя пишет ТЗ, но при этом должен угадать, чего на самом деле хочет заказчик. В принципе, это возможно (для участников шоу «Битва Экстрасенсов»), но маловероятно. У меня был опыт создания подробных ТЗ, которые на этапе внедрения претерпевали изменения порядка 30%. Обычная история: в процессе работы над проектом у заказчика появлялись новые идеи, их приходилось учитывать, отказываясь от предыдущих решений. Потому я не сторонник очень подробных ТЗ. Они отнимают много времени, а в итоге будут скорректированы на этапе опытной эксплуатации и внедрения. Если не сделать корректировку, можно испортить отношения с заказчиком. При попытке сослаться на подробное ТЗ в ответ вы услышите – «ну, вы же специалисты, должны были сами все знать заранее».
Я считаю, в ТЗ должны быть отражены только общие блоки работ с описанием ожидаемых результатов. Пусть оно достаточно точно описывает, что хочет получить заказчик, и что должен сделать исполнитель. Корректировка ТЗ неизбежна из-за того, что при появлении нового инструмента у заказчика обязательно появятся новые бизнес-процессы. Попытка сохранить прежние бизнес-процессы приведет к провалу проекта. Конечно, не все старое отметается полностью, оно корректируется в соответствии с возросшими возможностями предприятия при наличии информационной системы. Максимум, на чем должно останавливаться ТЗ – списки документов для обработки системой с их образцами. Таким образом, составленное ТЗ не изменится по части общих требований, фактически оно будет уточняться в процессе внедрения, вплоть до конкретных полей и процессов. При этом исполнитель в любом случае знает ожидаемый объем работ. Для успешного проекта требуется 1-2 итерации: внедряется определенный объем выполненных работ, и по результатам заказчик согласовывает коррекцию с исполнителем. Время, которое можно было потратить на излишнюю детализацию ТЗ, гораздо эффективнее использовать для итерационных корректировок системы в соответствии с результатом тестовой эксплуатации.
Есть еще один вариант составления ТЗ: в нем декларируется конечная цель заказчика. И тут вы можете сразу заметить противоречия с предыдущем написанным тестом. Это случай составления проекта, в котором информационная система является только частью. У меня был опыт внедрения комплексной системы управления компаний, где основная сумма по контакту выплачивалась в случае, если заказчик получит увеличение оборота в два раза. Спрашивается, это как? Ответ прост: цели заказчика - автоматизация и оптимизация бизнес процессов копании, ускорение процесса работы с клиентами, точный учет затрат по контрактам, точный расчет бонусов менеджерам, участвующим в контрактах, финансовое планирование. Исходя из того, что все эти задачи не были решены, я подписал контракт. К сожалению, достигнуть 100% увеличения объема оборота у заказчика за 1 год не удалось, но 83% тоже хорошо. Мое вознаграждение было выплачено пропорционально.
Следующим важным документом для успешного выполнения работ является план-график работ.
План-график работ
План-график - документ, содержащий план конкретных работ, в котором описаны действия, которые должны выполнить как заказчик , так и исполнитель . План-график нужен для оперативного контроля за работой обеих сторон. Как правило, в нем перечисляются все системы и подсистемы со своими процессами, документами, отчетами, которые будут разработаны и внедрены. К примеру: действия заказчика, связанные с организацией рабочих мест, прокладкой коммуникаций, обучением персонала и т.д. На каждом пункте плана-графика может быть проставлена цена и длительность, это дает возможность делать взаиморасчеты между исполнителем и заказчиком. Работы, конечно, могут идти параллельно. Хорошо использовать диаграммы Ганта или что-то аналогичное, но не обязательно.
Запуск системы в работу
Запуску системы предшествует тестирование исполнителем системы на примерах заказчика. После получения положительных результатов начинается работа по реальному внедрению и запуску системы. Если опытная эксплуатация делается только на опытных примерах без участия рядовых исполнителей заказчика, без использования реальных задач, она не достигнет поставленной цели. Целью же является сбор замечаний, которые необходимо устранить для перевода в промышленную эксплуатацию. Данный этап правильнее было бы назвать расширенным тестированием с привлечением исполнителей заказчика. Реальная опытная эксплуатация начинается после внедрения системы при участии, как минимум, 50-70% процентах рабочих мест.
Персонал проходит обучение, для пользователей составляются краткие инструкции. Этот этап может длиться от нескольких минут до нескольких недель. Хорошо работают методы экстремального программирования, когда поступившие замечания от сотрудников исполнителя сразу устраняются квалифицированными разработчиками заказчика, желательно на месте у заказчика. Тем самым за одну, максимум две недели можно решить основную массу проблем, связанных с запуском и адаптацией системы. Без масштабного запуска с неукоснительным требованием руководства заказчика введение в эксплуатацию может затягиваться на долгие месяцы. Если нет жесткого требования руководства, люди будут работать по-старому. При любых нововведениях у людей лишь возникнет ощущение, что им кто-то мешает жить.
После этапа опытной эксплуатации сразу следует промышленная. Отличие между ними только в количестве замечаний, которые должны быть устранены, и в отсутствии критических проблем, при наличии которых эксплуатация становится невозможной.
В итоге мы получаем такие этапы запуска и внедрения системы:
- Тестирование с привлечением сотрудников заказчика на реальных примерах;
- Опытная эксплуатация с немедленным устраняем возникающих проблем;
- Промышленная эксплуатация.
Этот метод был проверен мной многократно на предприятиях различных масштабов. Сотрудники компании заказчика в некоторые моменты испытывают дискомфорт, как и сотрудники исполнителя. Но, к счастью, дискомфорт этот быстро сходит на нет, и предприятие переходит в планомерную работу при конструктивном подходе к решению возникающих задач.
Теги: Добавить метки
Внедрение корпоративной ИС, разработанной самостоятельно или приобретенной у поставщика, зачастую сопровождается ломкой (перепроектированием) существующих на предприятии бизнес-процессов. Приходится перестраивать их под требования стандартов и логику внедряемой системы. Отметим сразу, что внедрение ИС решает ряд управленческих и технических проблем, однако порождает проблемы, связанные с человеческим фактором.
Внедрение информационной системы, как правило, значительно облегчает управление деятельностью предприятия, оптимизирует внутренние и внешние потоки информации, ликвидирует узкие места в управлении. Однако после того как система успешно установлена, "обкатана" в работе и показала свою эффективность, у части сотрудников выявляется нежелание использовать ИС в работе. В результате проведенного реинжиниринга становится ясно, что некоторые сотрудники в большой степени дублируют работу других или вовсе не нужны. Кроме того, внедрение КИС сопровождается обязательным обучением, но, как показывает российский опыт, желающих переучиваться не так много. Ломка старых навыков и прививание новых - долгий и трудный процесс!
Надо четко понимать, что корпоративная ИС призвана упростить управление организацией, улучшить процессы, усилить контроль и обеспечить этим конкурентные выгоды. Только с такой точки зрения можно оценивать пользу от ее внедрения.
Следуя этой логике, становится понятно, что хотя корпоративная ИС предназначена в целом для обеспечения всех пользователей необходимой информацией, управление разработкой и внедрение КИС является прерогативой высшего руководства компании! Понимают ли это руководители?
Здесь тоже приходится бороться с живучими стереотипами. "Зачем мне корпоративная система, если дела на предприятии и так идут хорошо?". "Зачем, что-то ломать, если все работает?". Но ведь ломать-то чаще всего и не надо. На первом этапе нужно лишь грамотно и корректно формализовать и перенести идентифицированные процессы, в рамках которых живет предприятие, в корпоративную ИС. Подобная формализация лишь отточит, отшлифует удачные маркетинговые и производственные находки, оптимизирует процесс управления и контроля и позволит в дальнейшем проводить целенаправленные изменения.
Внедрение новой ИС - сложный процесс, длящийся от нескольких месяцев для небольших ИС до нескольких лет для ИС больших распределенных компаний с широкой номенклатурой продуктов и большим количеством поставщиков. Успех проекта по разработке (или приобретению) и внедрению ИС во многом зависит от готовности предприятия к ведению проекта, личной заинтересованности и воли руководства, реальной программы действий, наличия ресурсов, обученного персонала, способности к преодолению сопротивления на всех уровнях сложившейся организации.
К настоящему времени сложился стандартный набор приемов внедрения ИС. Основное правило: выполнять обязательные фазы последовательно и не пропускать ни одной из них.
Критически важными для внедрения являются следующие факторы:
наличие четко сформулированных целей проекта и требований к ИС;
наличие стратегии внедрения и использования ИС;
проведение предпроектного обследования предприятия и построения моделей "Как есть" и "Как будет";
планирование работ, ресурсов и контроль выполнения плана внедрения;
участие высшего руководства во внедрении системы;
проведение работ по внедрению ИС специалистами по интегрированию систем совместно со специалистами предприятия;
регулярный мониторинг качества выполняемых работ;
быстрое получение положительных результатов хотя бы в части внедренных модулей ИС или в процессе ее опытной эксплуатации.
Перед началом разработки проекта внедрения необходимо:
максимально формализовать цели проекта внедрения ИС;
оценить минимально необходимые затраты и статьи расхода;
установить высокий приоритет проекта внедрения перед остальными текущими проектами;
наделить руководителя проекта максимально возможными полномочиями;
провести массовую просветительскую работу с персоналом предприятия с целью довести до каждого важность и необходимость предстоящих преобразований;
разработать организационные меры для применения новых информационных технологий;
распределить персональную ответственность по всем этапам внедрения и опытной эксплуатации.
Необходимо также определить функциональные сферы внедрения модулей информационной системы:
организационное управление;
организационно-административное обеспечение;
управление бизнес-процессами;
управленческий, планово-финансовый и бухгалтерский учет;
управление персоналом;
управление документацией;
управление материально-техническим обеспечением;
управление связями с клиентами и внешней средой.
Кроме того, что перечислено выше, надо задать технологические требования к внедрению ИС:
системная платформа - внедрение и адаптация готового решения от производителя или разработка на заказ в соответствии с техническим заданием заказчика;
интегрируемость - данные хранятся и обрабатываются в едином информационном пространстве; это обеспечивает их полноту, непротиворечивость, достоверность и возможность многократного использования; система может включать в себя вновь разработанные и уже используемые технологии и приложения;
адаптируемость - система настраивается в соответствии с требованиями заказчика и на особенности информационного поля заказчика;
распределенность - система может эффективно функционировать в территориально удаленных подразделениях и филиалах предприятия;
масштабируемость - система может выполняться в виде каркаса, содержащего базовые модули, и дополняться в соответствии с требованиями изменяющейся внешней и внутренней среды.
Внедрение корпоративной ИС, разработанной самостоятельно или приобретенной у поставщика, зачастую сопровождается ломкой (перепроектированием) существующих на предприятии бизнес-процессов . Приходится перестраивать их под требования стандартов и логику внедряемой системы. Отметим сразу, что внедрение ИС решает ряд управленческих и технических проблем, однако порождает проблемы, связанные с человеческим фактором .
Внедрение информационной системы, как правило, значительно облегчает управление деятельностью предприятия, оптимизирует внутренние и внешние потоки информации , ликвидирует узкие места в управлении. Однако после того как система успешно установлена, "обкатана" в работе и показала свою эффективность, у части сотрудников выявляется нежелание использовать ИС в работе. В результате проведенного реинжиниринга становится ясно, что некоторые сотрудники в большой степени дублируют работу других или вовсе не нужны. Кроме того, внедрение КИС сопровождается обязательным обучением, но, как показывает российский опыт , желающих переучиваться не так много. Ломка старых навыков и прививание новых - долгий и трудный процесс!
Надо четко понимать, что корпоративная ИС призвана упростить управление организацией, улучшить процессы, усилить контроль и обеспечить этим конкурентные выгоды. Только с такой точки зрения можно оценивать пользу от ее внедрения.
Следуя этой логике, становится понятно, что хотя корпоративная ИС предназначена в целом для обеспечения всех пользователей необходимой информацией, управление разработкой и внедрение КИС является прерогативой высшего руководства компании! Понимают ли это руководители?
Здесь тоже приходится бороться с живучими стереотипами. "Зачем мне корпоративная система, если дела на предприятии и так идут хорошо?". "Зачем, что-то ломать, если все работает?". Но ведь ломать-то чаще всего и не надо. На первом этапе нужно лишь грамотно и корректно формализовать и перенести идентифицированные процессы, в рамках которых живет предприятие, в корпоративную ИС. Подобная формализация лишь отточит, отшлифует удачные маркетинговые и производственные находки, оптимизирует процесс управления и контроля и позволит в дальнейшем проводить целенаправленные изменения.
Внедрение новой ИС - сложный процесс, длящийся от нескольких месяцев для небольших ИС до нескольких лет для ИС больших распределенных компаний с широкой номенклатурой продуктов и большим количеством поставщиков. Успех проекта по разработке (или приобретению) и внедрению ИС во многом зависит от готовности предприятия к ведению проекта, личной заинтересованности и воли руководства, реальной программы действий, наличия ресурсов, обученного персонала, способности к преодолению сопротивления на всех уровнях сложившейся организации.
К настоящему времени сложился стандартный набор приемов внедрения ИС. Основное правило: выполнять обязательные фазы последовательно и не пропускать ни одной из них .
Критически важными для внедрения являются следующие факторы:
- наличие четко сформулированных целей проекта и требований к ИС;
- наличие стратегии внедрения и использования ИС;
- проведение предпроектного обследования предприятия и построения моделей "Как есть" и "Как будет";
- планирование работ, ресурсов и контроль выполнения плана внедрения;
- участие высшего руководства во внедрении системы;
- проведение работ по внедрению ИС специалистами по интегрированию систем совместно со специалистами предприятия;
- регулярный мониторинг качества выполняемых работ;
- быстрое получение положительных результатов хотя бы в части внедренных модулей ИС или в процессе ее опытной эксплуатации .
Перед началом разработки проекта внедрения необходимо:
- максимально формализовать цели проекта внедрения ИС;
- оценить минимально необходимые затраты и статьи расхода;
- установить высокий приоритет проекта внедрения перед остальными текущими проектами;
- наделить руководителя проекта максимально возможными полномочиями;
- провести массовую просветительскую работу с персоналом предприятия с целью довести до каждого важность и необходимость предстоящих преобразований;
- разработать организационные меры для применения новых информационных технологий;
- распределить персональную ответственность по всем этапам внедрения и опытной эксплуатации .
Необходимо также определить функциональные сферы внедрения модулей информационной системы:
- организационное управление;
- организационно-административное обеспечение;
- управление бизнес-процессами ;
- управленческий, планово-финансовый и бухгалтерский учет;
- управление персоналом ;
- управление документацией;
- управление материально- техническим обеспечением ;
- управление связями с клиентами и внешней средой.
Кроме того, что перечислено выше, надо задать технологические требования к внедрению ИС:
- системная платформа - внедрение и адаптация готового решения от производителя или разработка на заказ в соответствии с техническим заданием заказчика;
- интегрируемость - данные хранятся и обрабатываются в едином информационном пространстве; это обеспечивает их полноту, непротиворечивость, достоверность и возможность многократного использования; система может включать в себя вновь разработанные и уже используемые технологии и приложения;
- адаптируемость - система настраивается в соответствии с требованиями заказчика и на особенности информационного поля заказчика;
- распределенность - система может эффективно функционировать в территориально удаленных подразделениях и филиалах предприятия;
- масштабируемость - система может выполняться в виде каркаса, содержащего базовые модули, и дополняться в соответствии с требованиями изменяющейся внешней и внутренней среды.
Основные фазы внедрения информационной системы
Фаза "Предварительные работы по подготовке проекта внедрения ИС" . В ходе предпроектного обследования предприятия ( рис. 8.4) происходит сбор подробной информации о структурном построении организации, функциональных связях, системе управления, об основных бизнес-процессах, о потоках внутри предприятия ( Control Flow , Doc Flow , Data Flow , Work Flow , Cash Flow ), необходимой для построения соответствующих моделей и выбора объектов для автоматизации. Оцениваются сроки, ресурсы, виды и объемы работ, номенклатура и стоимость программно-аппаратных и телекоммуникационных средств, стоимость обучения персонала и т. д.
Фаза "Подготовка проекта" . После завершения первой фазы осуществляется предварительное планирование и формирование процедур запуска проекта:
- формирование проектной и экспертной групп;
- распределение полномочий и ответственности;
- определение организационно-технических требований к процессу внедрения;
- уточнение спецификаций и ожиданий заказчика;
- обучение группы внедрения, состоящей из специалистов предприятия-заказчика.
Последний, очень важный момент почему-то часто пропускается при составлении плана внедрения. А ведь от него в огромной степени зависит успех всего проекта! После начала финансирования проект считается запущенным к исполнению.
Фаза "Концептуальная проработка проекта" . В течение этой фазы:
- формируется и утверждается концептуальный проект;
- достигается обязательное однозначное понимание намерений всех участников проекта относительно внедряемой ИС;
- уточняются и конкретизируются цели и задачи проекта ;
- определяются размеры прототипа системы;
- согласуются укрупненный план работы, последовательность этапов и условия опытной эксплуатации , планово-финансовые и отчетные показатели;
При этом все указанные действия в обязательном порядке документируются, согласуются и утверждаются всеми заинтересованными и ответственными сторонами.
Фаза "Реализация проекта" . Во время проведения основных работ по внедрению создается, устанавливается и конфигурируется системная среда, определяются процедуры системного администрирования, устанавливаются основные программно-аппаратные комплексы и приложения. В системе настраиваются организационно-штатные и организационно- функциональные структуры предприятия с использованием таких организационных единиц, как филиал, департамент, отдел, рабочая группа и т. д.
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Подобные документы
- Управление проектами
- Тестирование с привлечением сотрудников заказчика на реальных примерах;
- Опытная эксплуатация с немедленным устраняем возникающих проблем;
- Промышленная эксплуатация.
Классификация автоматизированных информационных систем. Классические примеры систем класса А, B и С. Основные задачи и функции информационных систем (подсистем). Информационные технологии для управления предприятием: понятие, компоненты и их назначение.
контрольная работа , добавлен 30.11.2010
Роль структуры управления в информационной системе. Примеры информационных систем. Структура и классификация информационных систем. Информационные технологии. Этапы развития информационных технологий. Виды информационных технологий.
курсовая работа , добавлен 17.06.2003
Информационные системы - обычный программный продук, но они имеют ряд существенных отличий от стандартных прикладных программ и систем. Классификация, области применения и реализации информационных систем. Фазы проектирования информационных систем.
реферат , добавлен 05.01.2010
Задачи информационных потоков в логистике. Виды и принципы построения, структура и элементы информационных логистических систем, основные требования к ним. Рекомендации по созданию, внедрению и режиму работы информационных систем в сфере логистики.
реферат , добавлен 14.01.2011
Принцип работы и задачи информационных систем управления проектами. Методы критического пути, анализа и оценки планов. Сетевые модель и график, виды путей. Информационный обмен между предприятиями, классификация информационных систем и их рынки сбыта.
контрольная работа , добавлен 18.11.2009
Принципы классификации управленческих информационных систем. Особенности информационных систем управления в государственных структурах. Средства автоматизации и хранения информации. Модернизация системы электронного документооборота казначейства.
дипломная работа , добавлен 20.09.2013
Предмет и основные понятия информационных систем. Базовые стандарты корпоративных информационных систем. Характеристика входящих и исходящих потоков информации. Основные понятия искусственного интеллекта. Обеспечение безопасности информационных систем.
У меня есть многолетний опыт внедрения и последующего сопровождения информационных систем на различных предприятиях. Опыт, в большинстве случаев, был успешным – но здесь я хочу побеседовать, в первую очередь, о причинах, ведущих к неудаче в этом деле, предостеречь вас от возможных ошибок. Я означу собственный метод внедрения, который я использовал неоднократно и который помогает избежать большинства из них.
Первая и самая главная причина провала: некорректно поставленная цель для информационной системы .
Это один из основных вопросов для любого проекта вообще. Заказчик зачастую выбирает цель, которая не имеет к информационной системе никакого отношения, или же зависит от нее незначительно. Примеры: увеличение продаж, занятие большей доли рынка, создание другой культуры управления предприятием и т. д. Но если компания производит товар, спрос на который падает – как тут поможет информационная система? Проблему здесь должно решать подразделение маркетинга. Если нужно изменить культуру предприятия – это вопрос управления персоналом и генерального директора. У некоторых, однако, теплится надежда, что стоит отдать деньги за информационную систему - и проблемы, связанные с организаций бизнеса, решатся сами собой. Обещания продавцов, «впаривающих» дорогие, иностранного производства, многократно проверенные и построенные на «лучших мировых бизнес-практиках» системы лишь укрепляют эту веру. Но на деле компания с неэффективным стилем управления останется неэффективной, только уже с информационной системой. Если на вашу продукцию упал спрос, он тоже не изменится никак. Правда, информационная система позволит вам быстро и точно подсчитать убытки, в том числе и от ее внедрения.
Корректно поставленная цель внедрения информационной системы - залог успеха этого внедрения. Правильны цели, связанные с обработкой информации: хранение, поиск данных, задачи, связанные с расчетами, группировкой, анализом. При внедрении системы все это требовать меньше времени. Помните, однако, что ускорение неудачных процессов приведет к еще более неудачному результату для компании, чем было бы без системы.
Вот один из недавних случаев на переговорах с заказчиком. Заказчик хочет сменить систему конфигурирования изделия, надеясь, что это упорядочит работу производства. С его слов, новая система должна предоставить только ограниченный выбор доступных опций изделий. Тогда производству и отделу согласования будет проще работать, появится набор стандартных решений. У заказчика, однако, уже есть конфигуратор. Сразу возник вопрос: зачем менять? Ответ потрясающий: другой конфигуратор «заставит нас работать правильно», создать необходимую документацию на изделие, изменить схемы обработки заказов и скорректировать культуру работы с заказчиком. Получается, менеджеры понимают, в чем проблема, но расписываются в собственном бессилии изменить ситуацию и перекладывают трудности по реорганизации бизнес-процессов на подразделение, которое за это не отвечает. Как правило, такой проект завершается крахом или затягивается на долгие годы.
Даже если предположить, что специалисты-информационщики знают, как следует изменить бизнес-процессы (с логикой у нас порядок), у них все равно нет нужного административного ресурса, да и ожидаемый результат зависит, в первую очередь, не от программного обеспечения. Здесь явно путается следствие и причина. Допустим, есть предприятие А с информационной системой ABC. Предприятие работает стабильно, нет авралов, неразберихи, заказы выполняются в срок, есть планомерная деятельность отлаженного механизма. Можно сделать вывод, что все хорошо благодаря системе ABC, но это 100% не так. Наличие системы ABC у предприятия A, кончено же, вносит свой вклад в бизнес, но не является ключевым. Если руководство некоего предприятия Б решило внедрить у себя систему ABC в надежде, что после ее внедрения предприятие Б тоже будет работать так же, как A, его ждет сюрприз. Деньги будут потрачены, но ожидаемый эффект не наступит, т.к. методика работы на предприятии Б не изменится.
Эффективные цели
Повторюсь – цели, которые я считаю эффективными при внедрении информационной системы, связаны с ускорением существующих бизнес-процессов или созданием новых для обработки данных. Не стоит перекладывать на информационную систему задачи других подразделений, особенно без права влиять на эти процессы.
Внедрение информационной системы позволяет запустить бизнес-процессы, которые прежде не имели права на существование из-за неприемлемых сроков выполнения. Более того, я считаю, что запуск новых бизнес-процессов - обязательное условие для успешного внедрения системы. Очевидно, если раньше мы использовали напильник для выполнения работ, а теперь у нас станок, это будет другой процесс. Если планирование было налажено плохо, станок, из-за своей производительности, принесет компании еще больший убыток.
Итак, с целями мы определились, теперь осталось правильно составить техническое задание.
Техническое задание
Это вторая по важности составляющая успеха при внедрении информационной системы. Напомню, эффективная цель – ускорение бизнес процессов, которых может быть еще не существует. Заказчик только в общих чертах понимает, что ему нужно. Хорошим вариантом считается уже на первых этапах работы составить подробное многостраничное ТЗ. Это работает, особенно для исполнителя по контракту. Заказчик все подписывает, не до конца понимая, что именно сделает исполнитель. А между тем, за каждое новое поле или форму, не записанные в ТЗ, исполнитель запросто попросит с заказчика еще денег. В итоге заказчик получит процесс с неполными или избыточными данными, хотя формально контракт был выполнен в точном соответствии с требованием. Заказчик будет недоволен и во второй раз к этому исполнителю не обратится.
Получается, что не заказчик подписал неподходящее ТЗ, а исполнитель разработал и предложил совсем не то – не угадал, о чем мечтал заказчик. Замечаете парадокс? Исполнитель сам для себя пишет ТЗ, но при этом должен угадать, чего на самом деле хочет заказчик. В принципе, это возможно (для участников шоу «Битва Экстрасенсов»), но маловероятно. У меня был опыт создания подробных ТЗ, которые на этапе внедрения претерпевали изменения порядка 30%. Обычная история: в процессе работы над проектом у заказчика появлялись новые идеи, их приходилось учитывать, отказываясь от предыдущих решений. Потому я не сторонник очень подробных ТЗ. Они отнимают много времени, а в итоге будут скорректированы на этапе опытной эксплуатации и внедрения. Если не сделать корректировку, можно испортить отношения с заказчиком. При попытке сослаться на подробное ТЗ в ответ вы услышите – «ну, вы же специалисты, должны были сами все знать заранее».
Я считаю, в ТЗ должны быть отражены только общие блоки работ с описанием ожидаемых результатов. Пусть оно достаточно точно описывает, что хочет получить заказчик, и что должен сделать исполнитель. Корректировка ТЗ неизбежна из-за того, что при появлении нового инструмента у заказчика обязательно появятся новые бизнес-процессы. Попытка сохранить прежние бизнес-процессы приведет к провалу проекта. Конечно, не все старое отметается полностью, оно корректируется в соответствии с возросшими возможностями предприятия при наличии информационной системы. Максимум, на чем должно останавливаться ТЗ – списки документов для обработки системой с их образцами. Таким образом, составленное ТЗ не изменится по части общих требований, фактически оно будет уточняться в процессе внедрения, вплоть до конкретных полей и процессов. При этом исполнитель в любом случае знает ожидаемый объем работ. Для успешного проекта требуется 1-2 итерации: внедряется определенный объем выполненных работ, и по результатам заказчик согласовывает коррекцию с исполнителем. Время, которое можно было потратить на излишнюю детализацию ТЗ, гораздо эффективнее использовать для итерационных корректировок системы в соответствии с результатом тестовой эксплуатации.
Есть еще один вариант составления ТЗ: в нем декларируется конечная цель заказчика. И тут вы можете сразу заметить противоречия с предыдущем написанным тестом. Это случай составления проекта, в котором информационная система является только частью. У меня был опыт внедрения комплексной системы управления компаний, где основная сумма по контакту выплачивалась в случае, если заказчик получит увеличение оборота в два раза. Спрашивается, это как? Ответ прост: цели заказчика - автоматизация и оптимизация бизнес процессов копании, ускорение процесса работы с клиентами, точный учет затрат по контрактам, точный расчет бонусов менеджерам, участвующим в контрактах, финансовое планирование. Исходя из того, что все эти задачи не были решены, я подписал контракт. К сожалению, достигнуть 100% увеличения объема оборота у заказчика за 1 год не удалось, но 83% тоже хорошо. Мое вознаграждение было выплачено пропорционально.
Следующим важным документом для успешного выполнения работ является план-график работ.
План-график работ
План-график - документ, содержащий план конкретных работ, в котором описаны действия, которые должны выполнить как заказчик , так и исполнитель . План-график нужен для оперативного контроля за работой обеих сторон. Как правило, в нем перечисляются все системы и подсистемы со своими процессами, документами, отчетами, которые будут разработаны и внедрены. К примеру: действия заказчика, связанные с организацией рабочих мест, прокладкой коммуникаций, обучением персонала и т.д. На каждом пункте плана-графика может быть проставлена цена и длительность, это дает возможность делать взаиморасчеты между исполнителем и заказчиком. Работы, конечно, могут идти параллельно. Хорошо использовать диаграммы Ганта или что-то аналогичное, но не обязательно.
Запуск системы в работу
Запуску системы предшествует тестирование исполнителем системы на примерах заказчика. После получения положительных результатов начинается работа по реальному внедрению и запуску системы. Если опытная эксплуатация делается только на опытных примерах без участия рядовых исполнителей заказчика, без использования реальных задач, она не достигнет поставленной цели. Целью же является сбор замечаний, которые необходимо устранить для перевода в промышленную эксплуатацию. Данный этап правильнее было бы назвать расширенным тестированием с привлечением исполнителей заказчика. Реальная опытная эксплуатация начинается после внедрения системы при участии, как минимум, 50-70% процентах рабочих мест.
Персонал проходит обучение, для пользователей составляются краткие инструкции. Этот этап может длиться от нескольких минут до нескольких недель. Хорошо работают методы экстремального программирования, когда поступившие замечания от сотрудников исполнителя сразу устраняются квалифицированными разработчиками заказчика, желательно на месте у заказчика. Тем самым за одну, максимум две недели можно решить основную массу проблем, связанных с запуском и адаптацией системы. Без масштабного запуска с неукоснительным требованием руководства заказчика введение в эксплуатацию может затягиваться на долгие месяцы. Если нет жесткого требования руководства, люди будут работать по-старому. При любых нововведениях у людей лишь возникнет ощущение, что им кто-то мешает жить.
После этапа опытной эксплуатации сразу следует промышленная. Отличие между ними только в количестве замечаний, которые должны быть устранены, и в отсутствии критических проблем, при наличии которых эксплуатация становится невозможной.
В итоге мы получаем такие этапы запуска и внедрения системы:
Этот метод был проверен мной многократно на предприятиях различных масштабов. Сотрудники компании заказчика в некоторые моменты испытывают дискомфорт, как и сотрудники исполнителя. Но, к счастью, дискомфорт этот быстро сходит на нет, и предприятие переходит в планомерную работу при конструктивном подходе к решению возникающих задач.
