Для ответа на этот вопрос я пару предложений потрачу на объяснение сути. Есть всего два внятных ОРГАНИЗАЦИОННЫХ способа создать информационную систему уровня ERP. Они НЕ ЗАВИСЯТ от того, кто и как делает инфосистему, какой бюджет и за какое время нужно получить результат. Первый из подходов - почасовые услуги (они же работы по TM или "почасовка"). По научной классификации - это процессные подходы. И то, что на процессные подходы взваливают получение результата, уже само по себе является ошибкой. Не для этого они были придуманы.
Краткая суть этих процессных/почасовых услуг - вы берете у кого-то в аренду (у рынка, у подрядчика или у своего внутреннего подрядчика) неких IT-специалистов и расплачиваетесь за их услуги в конце месяца пропорционально чему-то. Обычно это некий след деятельности. Как это ни смешно, но самый распространенный на рынке способ получить почасовые услуги - это иметь собственный внутренний IT отдел. Следующий, не такой болезненный способ, получить такие же услуги - это купить их на рынке. По сути, все тоже самое, но это не так больно, когда все прогнозируемо не получается. Чуть позже я расскажу почему, и почему я так топлю за второй подход. Назовем его "Проектный".
Проектный подход – это когда мы эти интеллектуальные упражнения IT-специалистов организовываем, в них появляется смысл (результат в заданную дату и бюджет). И дальше, с помощью специального набора техник, проектная группа ведется к этому результату с разной степенью эффективностью. Как вы заметили в первом подходе, смысла в виде результата в нужную дату за фиксированные деньги нет.
Итак, основным отличием "проектных работ" от "почасовых услуг" является то, что проектные работы специальным образом организованы, чтобы выдать результат к зафиксированной дате с зафиксированным бюджетом. Есть специальные техники и технологии, которые позволяют внести эту определенность в деятельность IT-коллектива. И совершенно неважно, есть ли у вас эти ресурсы в штате или нет. Стоят они вам чего-то, или условно бесплатны.
Отдельным постом я напишу (чтобы не мешать все в одну статью) в деталях, что именно делается в каждом из подходов, плюсы и минусы.
А ответ на вопрос в заголовке будет следующий: проектный подход необходим, когда необходимо получить какой-то новый результат, которого до этого не было. Обычно - это разовое воздействие на свою компанию, которое позволяет достичь некого нового свойства в вашей организации.
А "процессный/почасовой" подход необходим, когда необходимо добиться повышения качества УЖЕ СУЩЕСТВУЮЩИХ и ПОВТОРЯЮЩИХСЯ процессов.
Например, создать инфосистему - это задача для проектного подхода. А поддерживать эту инфосистему - это уже процессный подход. И чтобы совсем взорвать мозг, то создать НОВУЮ службу поддержки, то это тоже проектный подход :)
Цена боли.
Неправильный выбор подхода к снаряду резко снижает вероятность получения запланированного результата. Обычно в разы. Если условия сложные, то получения результата с помощью процессных подходов не исполнимо в принципе. То есть сколько людей ни нагони.
Парадокс в познании сути в том, что некоторые коллективы интуитивно используют проектные подходы, но контрактуются как процесс. Это снижает их проектные риски, потому что за все проектные ошибки заплатят по таймшиту. И сбивает с толку контролеров процесса. Потому что ряд выполняемых услуг невозможно пронаблюдать/зафиксировать.
И традиционно наглядный пример отличия процессных от проектных на интуитивно понятной людям отрасли - стройке. Представьте, что вам нужно построить торговый центр. «Золотой Вавилон» внутри города Москва. И вы берете идеального плиточника, человека по электрике и даже дизайнера интерьеров. И с помощью этих трех идеальных самих по себе людей начинаете строить огромный ТЦ. В Москве. И у вас ограниченный бюджет, и даже есть дедлайн, после которого вся затея резко теряет привлекательность.
Сторонники процессного подхода говорят, что достаточно накидать необходимых рабочих нужной компетенции, и для контроля по итогам месяца им оплачивать трудо-часы. Сторонники проектного подхода: формируют управляющую проектную группу, фиксируют границы проекта, планируют работы, деньги и ресурсы, планируют состав рабочей проектной группы и делают массу неочевидных для идеального плиточника+электрика+дизайнера штук. Включая мракобесные работы, типа работы с административным ресурсом, поиск оптимального инвестора, создание фондов, сценариев рисков и прочего.
И все было бы не так поучительно, если бы многие Заказчики ERP в который раз не ходили за результатом к своему знакомому хорошему программисту (плиточнику/электрику/дизайнеру).
Роман Неверов
Отказ от проектного подхода там, где он был необходим
3 Июля 2018 10:45
Роман Неверов об организационных способах создания информационной системы уровня ERP.