Как не впустую потратить ресурсы и не пожалеть о внедрении программного обеспечения
Предпосылки
Многолетняя работа в проектных продажах по доработке и внедрению программного обеспечения обогатила возможностью собрать и систематизировать ошибки и проблемные точки проектов.
Так как работа в компании накладывает ряд непреодолимых ограничений, что, зачастую, снижает качество работ, перешел во фриланс. Появилось немного больше свободного времени, как минимум на транспортную составляющую, что и позволило поделиться опытом.
Предмет статьи
Как получить ожидаемый результат от проекта внедрения программного обеспечения.
Отступление I
В статье будет немало камней в огород IT-специалистов. Именно поэтому и выбрана площадка для публикации. Полагаю, данный материал поможет вам избежать неприятных ситуаций.
Граничные условия
О каких проектах и предприятиях пойдет речь. Автоматизация бизнес-процессов компании. Не рассматриваются вопросы автоматизации технологического оборудования.
Предприятия:
Небольшие. Как правило решают вопросы использованием «коробочных» продуктов с минимальными настройками. Проектные внедрения не требуются.
Средние. Наличие структурных подразделений, возможно филиалов. Появляются регламентирующие документы. Несколько уровней менеджмента. Как правило, уже недостаточно функционала стандартных решений и требуются процессы доработки программного обеспечения и его внедрения.
Крупные предприятия. Практически всегда требуется проектный подход.
Холдинговые структуры. Если речь идет об отдельных предприятиях — всё, как и в П.3. В случае включения в проект головной управляющей компании, как правило, требуется существенная доработка. Вопрос только в том, что будем дорабатывать: бизнес-процессы, или программное обеспечение.
Глобальные компании. Зачастую с государственном участием. Пожалуй, требуют отдельного рассмотрения. Процедуры принятия решений и контроля выполнения работ существенно влияют на все процессы подготовки и реализации проекта.
Как вы уже поняли, рассматриваю компании упомянутые в П.2 — П.4.
Ну, и наконец, приступаем к теме статьи.
Истоки. Или откуда ноги растут
Принято решение о внедрении программного обеспечения.
Иногда под влиянием сотрудников — мы перегружены вспомогательной работой, нам некогда качественно выполнять основные функции, или что-то подобное. Кстати, они далеко не всегда заинтересованы в успешной реализации.
Иногда волевым решением руководства. Причем не всегда обоснованном, просто так принято. Чаще по причине потери управляемости процессом вследствие не адекватной отчетности.
Иногда (редко) по инициативе IT-подразделений.
В любом случае (чаще всего), найти исполнителей поручается отделу IT. Все логично, кто же, кроме них сможет разобраться в различных продуктах и исполнителях.
И вот проблема первая
Мы совсем забыли о цели мероприятия. Я сознательно не пишу о внутренних процессах компании по подготовке требований к автоматизации. Такие документы, как правило есть. Иногда в самом общем виде, бывает в формате технического задания. Чаше всего содержат общие требования (скопированные из предыдущего или интернета), но, практически никогда не зафиксированы цели и показатели их достижения.
Да, цели описаны в общем виде (такой раздел есть в любом документе), но такое описание не дает возможности оценить успешность реализации проекта. Скажем прямо, исполнители не любят наличие в контракте условия по достижению целевых показателей. Но, вы же, как Заказчик, планируете внедрение продукта для успешности своего бизнеса, а не ради благосостояния разработчиков программного обеспечения.
К этой теме буду возвращаться еще не раз, поэтому различные аспекты этой проблемы будут раскрыты в кейсах.
Предпроектное обследование
Профессиональные исполнители обязательно предложат провести предпроектное обследование. Варианты от полного аудита бизнес-процессов и разработки общего/частного технического задания (будет зависеть от объема проекта) до краткого анализа требований с согласованием с владельцем бизнес-процесса.
Такая работа необходима обоим сторонам контракта. Исполнителю для предварительной оценки стоимости реализации, а Заказчику обеспечит понимание масштаба бедствия, требуемые ресурсы и, естественно, полную информацию для принятия решения.
В обязательном порядке обследование должно заканчиваться отчетом, содержащим, как минимум описание текущего состояния (как есть), предлагаемые решения, описание «как будет», план-график реализации и, естественно, оценку необходимых ресурсов.
Отступление II
Директора компаний практически, никогда не знают всех тонкостей реализации бизнес-процессов. Да и не их эта задача. Ну, не должен знать директор, например, в какую сторону и с каким моментом должна быть закручена гайка где-то там в недрах двигателя.
Предупреждение
В рамках статьи не будет упоминаний имен, названий компаний, каких-либо иных персональных данных. Только обезличенные материалы.
Кейс 1
Исходные данные:
1. Компания оказывает услуги юридическим и физическим лицам;
2. Заказ выполняется в течении нескольких часов или суток;
3. Особенностью процесса принятия заказа является глубина исполнения при ограниченных ресурсах. То есть, сотрудник принимает заказ, который должен быть выполнен через 123 дня. На выполнение заказа требуется 2 часа. Более подробно описывать иные условия для наших целей не требуется. Иначе будет слишком узнаваемая компания.
4. Заказчик изучил рынок, готового решения не нашел;
5. Подобрать исполнителя поручено сотруднику IT подразделения компании, назовем его Х;
6. Х провел предварительные поиски и выбрал возможного исполнителя.
Реализация
От предпроектного обследования компания категорически отказалась. Причина: Х самостоятельно описал процесс, сформулировал требования и, что немаловажно, они утверждены директором. То есть, требуется только исполнитель на доработку программного обеспечения по ТЗ Заказчика
Исполнитель, изучив ТЗ, определился со сроками и стоимостью работ. Заказчика устроило предложение, контракт подписан.
Наступило время сдачи релиза для тестовой эксплуатации. Контрольный прогон системы с участием Х и руководства компании недоработок не выявил.
Система инсталлирована на технических средствах сотрудников, которые до этого момента ничего о ней не знали.
Понимаю, что вы уже знаете к какому результату мы пришли. Естественно, началось с мелких не критичных правок, но в итоге, неучтенные тонкости процесса похоронили всю систему. Реализация всех требований потребовала существенной переработки ядра решения и, фактически удвоения бюджета проекта.
Итог. Расстались недовольные друг другом. Заказчик своих ошибок не признал и менять бюджет проекта отказался. Исполнитель отказался перепроектировать систему за свой счет.
Продолжение следует
Уважаемый читатель. Это пробная статья. Если тема покажется Вам интересной и будут отклики и обсуждение, буду дополнять кейсами, которых скопилось не мало. Как успешных, так и провальных.
