Многие автотранспортные предприятия (АТП) стремятся повысить эффективность своей деятельности путем внедрения автоматизированных информационных систем (АИС). Разработать такую систему с нуля большинство перевозчиков не в силах, поскольку не имеют в данной области ни опыта, ни квалифицированных кадров. Поэтому приходится выбирать одну из существующих на рынке систем и приводить ее в соответствие со своими бизнес-процессами.
Покупка информационной системы для автоматизации учетно-аналитической деятельности — это только первый шаг. Программу нужно еще внедрить, а в 95% случаев — доработать. Чтобы пройти этот непростой путь и не «поскользнуться», обратимся к морфологической карте проблемы успешной доработки и внедрения информационной системы автотранспортного предприятия.
Цель проекта автоматизации
«Лоскутная» автоматизация плоха, во-первых, тем, что очень трудно добиться интеграции улучшений в решении отдельных задач управления. Во-вторых, она предъявляет повышенные требования к уровню компьютерной грамотности простых исполнителей. Кроме того, «лоскутная» автоматизация, как правило, не требует изменения самого автоматизируемого процесса, оставляя в стороне вопросы его интеграции с другими процессами.
На интеграцию и решительный пересмотр технологий выполнения рутинных операций ориентирован реинжиниринг. Однако на практике проектная группа предприятия почти никогда не получает реальных прав для изменения процессов. Радикальной перестройки не происходит, и проект начинает терять поддержку и со стороны руководства, и со стороны рядовых сотрудников.
Методы моделирования бизнеса
Стандартизированные методологии моделирования сложны для освоения даже членами проектной группы. И если им удастся добиться взаимопонимания между собой, вряд ли такого результата можно ожидать в масштабах всего предприятия. Сотрудники, сталкиваясь с диаграммами, построенными по формальным синтаксическим правилам, зачастую не могут ответить на принципиальный вопрос: правильно ли в модели описана их деятельность?
Средства моделирования
Хотя ручная технология обработки информации наиболее легка в освоении, она не способна обеспечить ни полноту и непротиворечивость модели, ни формат взаимодействия для коллектива бизнес-аналитиков. Лицензионные версии специализированных продуктов настолько дороги, что даже многие разработчики программного обеспечения для бизнеса признают нецелесообразным использование CASE-пакетов. Кроме того, они непросты в освоении, и зачастую к моменту предполагаемого завершения проекта члены проектной группы успевают только овладеть методами и средствами моделирования, тогда как руководство думает, что «программка уже работает».
Содержание технического задания
Техническое задание (ТЗ) может представлять собой совокупность требований к интерфейсу и результатам расчетов. В этом случае есть опасность, что разработчики доверятся клиенту и сделают все в строгом соответствии с его пожеланиями. Специфика бизнеса в этом случае останется за кадром, и у разработчиков не будет шанса оценить адекватность преобразования особенностей бизнес-процессов компании в требования к информационной системе.
Создание ТЗ в строгом соответствии с требованиями ГОСТов приведет к тому, что проектная группа вынужденно будет концентрироваться на технических вопросах, которые так или иначе уже реализованы в системе и решаться по-другому не будут.
Кроме того, многие пункты ТЗ, актуальные для формирования требований к информационным системам крупных компаний, не имеют никакого значения для перевозчиков среднего и даже крупного масштаба.
Тип договора на доработку
Фиксация в договоре формы оплаты как процента от роста доходов/прибыли компании-заказчика является следствием некоторого авантюризма разработчиков. Создание информационной системы — важнейший инфраструктурный проект в области управления фирмой. А инфраструктура, как известно, лишь создает предпосылки для повышения результативности и эффективности функционирования системы в целом. Точное следование ТЗ по определению неплодотворно, так как даже самый тщательно подготовленный проект не бывает реализован в точном соответствии с первоначальным планом вследствие динамично меняющейся внешней и отчасти внутренней среды.
Характер процесса доработки
«Водопадный» процесс и его модификации плохи прежде всего тем, что самые главные риски проекта внедрения остаются неразрешенными до самого последнего момента, то есть до этапов интеграции, тестирования и отладки. В результате, когда клиент надеется приступить к работе, выясняется, что в задуманном виде система не может быть реализована, а перестраивать архитектуру базы данных и приложений уже слишком поздно.
Итеративный процесс, напротив, хорош тем, что в результате каждой итерации появляется частично работающая реализация конечной системы. Причем желательно после внутреннего тестирования включать доработки непосредственно в производственный процесс, а не ждать выхода полнофункциональной бета-версии.
Функциональность и интерфейс: что первично?
Естественно, что в ТЗ определяются требования и к функциональности, и к интерфейсу. Однако следует признать, что один в один они не реализуются. На каком-то этапе доработки может возникнуть некий люфт: то ли пойти на поводу у конечных пользователей и больше внимания уделить эргономичности системы, то ли всегда держать в голове потребителей информации и заказчиков системы.
Например, генеральному директору важно, умеет ли система рассчитывать фактические затраты на эксплуатацию отдельных единиц техники или нет. И мнение диспетчера о том, удобно ли ему вводить путевки, учитываться не будет.
Взаимодействие заказчика и разработчика
Многие заказчики стремятся построить диалог с разработчиками исключительно в формате личных встреч на своей территории. Конечно, степень взаимопонимания в ходе таких встреч очень высока, но, к сожалению, не слишком велико количество решенных вопросов. Дистанционное общение, например по электронной почте, гораздо эффективнее, поскольку позволяет облечь свои мысли и предложения в точную и лаконичную форму.
В то же время полностью избежать личного общения невозможно, поскольку прочные контакты между ключевыми участниками проекта со стороны заказчика и разработчика являются надежной основой долговременного сотрудничества их компаний.
Таким образом, формулой успешной доработки и результативного внедрения автоматизированной информационной системы на современном автотранспортном предприятии является ориентация на комплексную автоматизацию бизнес-процессов и итеративную доработку конечного продукта. При этом, создавая системный и технический проекты будущей системы, не стоит зацикливаться на стандартизированных методологиях и «правильных» дорогостоящих программах. Следует максимизировать, насколько это возможно, функциональность продукта и жестко контролировать ход проекта.
Морфологическая карта проблемы успешной доработки и внедрения информационной системы АТП