Проблемы проектов комплексной автоматизации и их решения

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

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

ЗАЧЕМ ЭТО НУЖНО ЗАКАЗЧИКУ

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

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

  • объективное отображение своих бизнес-процессов (БП) — возможность планирования и управления ими;
  • реальную картину активов и пассивов предприятия. Также обеспечивается снижение скрытых затрат путем:
  • устранения дублирования информации и ее противоречивости;
  • снижения вероятности принятия ошибочных решений;
  • оптимизации бизнес-процессов;
  • снижения производственных потерь;
  • сокращения временных затрат на принятие решений;
  • контроля потоков любых ресурсов (фискальная функция).

Список можно продолжать, упомянем еще лишь один фактор — повышение имиджевого уровня компании перед своими контрагентами.

Если обратиться к BSC («системе сбалансированных показателей» для оценки деятельности предприятия), то можно утверждать, что качественная реализация ИТ-проекта не по «остаточному» принципу, помогает решить три группы задач BSC: инновационную, повышения качества внутренних процессов, повышения качества обслуживания клиентов. А это является фундаментом для достижения главной цели любой компании — хороших экономических показателей.

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

ЧТО ПРЕДШЕСТВУЕТ АВТОМАТИЗАЦИИ

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

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

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

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

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

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

КАК ПРОХОДИТ АДАПТАЦИЯ

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

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

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

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

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

ВАРИАНТЫ ВВОДА В ЭКСПЛУАТАЦИЮ

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

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

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

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

ЖИЗНЕННЫЙ ЦИКЛ ПРОДУКТА

Как продукт развивается дальше? По сути варианты можно разделить на две большие категории: развитие платформы и развитие прикладного функционала конкретного решения.

Развитие платформы SoftPro обеспечивается централизованно, оно включает в себя обновления для абсолютно всех наших клиентов. При этом обеспечивается совместимость версий. 90 % обновлений выпускаются в виде автоматизированных утилит, 10 % — в виде методик по реализации (это бывает, когда уникальные вещи, разработанные на предприятии, тесно переплетаются с нашими обновлениями).

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

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

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

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

Алексей КарножицкийАлексей Карножицкий
генеральный директор
группы компаний СофтПро

2008.02.19
19.03.2009
В IV квартале 2008 г. украинский рынок серверов по сравнению с аналогичным периодом прошлого года сократился в денежном выражении на 34% – до $30 млн (в ценах для конечных пользователей), а за весь календарный год – более чем на 5%, до 132 млн долл.


12.03.2009
4 марта в Киеве компания Telco провела конференцию "Инновационные телекоммуникации", посвященную новым эффективным телекоммуникационным технологиям для решения задач современного бизнеса.


05.03.2009
25 февраля в Киеве компания IBM, при информационной поддержке "1С" и Canonical, провела конференцию "Как сохранить деньги в условиях кризиса?"


26.02.2009
18-19 февраля в Киеве прошел юбилейный съезд ИТ-директоров Украины. Участниками данного мероприятия стали ИТ-директора, ИТ-менеджеры, поставщики ИТ-решений из Киева, Николаева, Днепропетровска, Чернигова и других городов Украины...


19.02.2009
10 февраля в Киеве состоялась пресс-конференция, посвященная итогам деятельности компании "DiaWest – Комп’ютерний світ" в 2008 году.


12.02.2009
С 5 февраля 2009 г. в Киеве начали работу учебные курсы по использованию услуг "электронного предприятия/ учреждения" на базе сети информационно-маркетинговых центров (ИМЦ).


04.02.2009
29 января 2009 года в редакции еженедельника "Computer World/Украина" состоялось награждение победителей акции "Оформи подписку – получи приз!".


29.01.2009
22 января в Киеве компания "МУК" и представительство компании Cisco в Украине провели семинар для партнеров "Обзор продуктов и решений Cisco Small Business"

 

 
 
Copyright © 1997-2008 ИД "Комиздат".