Предпосылки

Многолетняя работа в проектных продажах по доработке и внедрению программного обеспечения обогатила возможностью собрать и систематизировать ошибки и проблемные точки проектов.

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

Предмет статьи

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

Отступление I

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

Граничные условия

О каких проектах и предприятиях пойдет речь. Автоматизация бизнес-процессов компании. Не рассматриваются вопросы автоматизации технологического оборудования.

Предприятия:

1. Небольшие. Как правило решают вопросы использованием «коробочных» продуктов с минимальными настройками. Проектные внедрения не требуются.

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

3. Крупные предприятия. Практически всегда требуется проектный подход.

4. Холдинговые структуры. Если речь идет об отдельных предприятиях – всё, как и в П.3. В случае включения в проект головной управляющей компании, как правило, требуется существенная доработка. Вопрос только в том, что будем дорабатывать: бизнес-процессы, или программное обеспечение.

5. Глобальные компании. Зачастую с государственном участием. Пожалуй, требуют отдельного рассмотрения. Процедуры принятия решений и контроля выполнения работ существенно влияют на все процессы подготовки и реализации проекта.

Как вы уже поняли, рассматриваю компании упомянутые в П.2 – П.4.

Ну, и наконец, приступаем к теме статьи.

Истоки. Или откуда ноги растут

Принято решение о внедрении программного обеспечения.

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

Иногда волевым решением руководства. Причем не всегда обоснованном, просто так принято. Чаще по причине потери управляемости процессом вследствие не адекватной отчетности.  

Иногда (редко) по инициативе IT-подразделений.

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

И вот проблема первая

Мы совсем забыли о цели мероприятия. Я сознательно не пишу о внутренних процессах компании по подготовке требований к автоматизации. Такие документы, как правило есть. Иногда в самом общем виде, бывает в формате технического задания. Чаше всего содержат общие требования (скопированные из предыдущего или интернета), но, практически никогда не зафиксированы цели и показатели их достижения.

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

К этой теме буду возвращаться еще не раз, поэтому различные аспекты этой проблемы будут раскрыты в кейсах.

Предпроектное обследование

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

Такая работа необходима обоим сторонам контракта. Исполнителю для предварительной оценки стоимости реализации, а Заказчику обеспечит понимание масштаба бедствия, требуемые ресурсы и, естественно, полную информацию для принятия решения.

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

Отступление II

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

Предупреждение

В рамках статьи не будет упоминаний имен, названий компаний, каких-либо иных персональных данных. Только обезличенные материалы.

Кейс 1

Исходные данные:

1. 1.    Компания оказывает услуги юридическим и физическим лицам;

2. 2.    Заказ выполняется в течении нескольких часов или суток;

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

4. 4.    Заказчик изучил рынок, готового решения не нашел;

5. 5.    Подобрать исполнителя поручено сотруднику IT подразделения компании, назовем его Х;

6. 6.    Х провел предварительные поиски и выбрал возможного исполнителя.

Реализация

От предпроектного обследования компания категорически отказалась. Причина: Х самостоятельно описал процесс, сформулировал требования и, что немаловажно, они утверждены директором. То есть, требуется только исполнитель на доработку программного обеспечения по ТЗ Заказчика

Исполнитель, изучив ТЗ, определился со сроками и стоимостью работ. Заказчика устроило предложение, контракт подписан.

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

Система инсталлирована на технических средствах сотрудников, которые до этого момента ничего о ней не знали.

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

Итог. Расстались недовольные друг другом. Заказчик своих ошибок не признал и менять бюджет проекта отказался. Исполнитель отказался перепроектировать систему за свой счет.

Продолжение следует

Уважаемый читатель. Это пробная статья. Если тема покажется Вам интересной и будут отклики и обсуждение, буду дополнять кейсами, которых скопилось не мало. Как успешных, так и провальных.