1. Проект и Процесс противоположны по свойствам.

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

Процесс — часовой механизм.

Проект ограничен по времени, процесс (при наличии ресурсов) повторяется вечно.

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

Процесс — жестко структурирован (стандартизирован).

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

2. Математически, отношение между Проектом и Процессом формулируется как: Проект = дельта Процесса.

Словами, Проект — суть конечный набор изменений в Процессе (группе процессов) потребителя Проекта.

При этом, то, что является Проектом с точки зрения потребителя, с точки зрения поставщика (-ов) является конечным этапом Процесса последнего (процессов группы поставщиков Проекта)

Упрощенно говоря, Проект потребителя является Процессом поставщика.

Пример: строительство дома с последующим получением апартаментов в собственность является Проектом для будущего владельца квартиры — и Процессом для поставщиков строительства (включая строительную компанию-генподрядчика).

Какие же Процессы потребителя (покупателя) изменятся в результате реализации Проекта?

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

Транспортные процессы — на работу, с работы, в магазин, детский сад, школу, etc (адрес-то новый).

Изменений (дельт в каждом отдельном процессе квартировладельца) много, но их набор конечен.

А строительная компания перевезет технику на следующий участок (тоже этап процесса строительства) и продолжит возводить типовые коробки

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

Ровно потому, что среди пула покупателей всегда есть какая то доля, для которых эта закупка разовая (проект).

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

3. Процессы управляются в парадигме IEM Enterprise

Более того, с точки зрения кибернетики IEM, «Предприятие» как таковое является группой (узлом) процессов, объединенных общим центром принятия решений.

При этом основные бизнес-процессы Предприятия, на которых создается стоимость для потребителей, являются участками глобальных цепочек создания стоимости (global value chains).

С высоты птичьего полета, внутри многомерной структуры глобальных value chains каждое Предприятие есть узел колоссальной паутины экономических отношений человечества.

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

Ни больше, ни меньше.

Приближение реального предприятия к кибернетическому идеалу IEM Enterprise математически гарантирует наивысшую достижимую операционную прибыль^* в заданных рыночных условиях.

И наоборот.

(*) В средне- и долгосрочном периоде.
В моменте традиционные административные мероприятия могут дать лучший результат — с гарантированным системным эффектом обратного характера.

4. Проект управляется в ERP парадигме.

Точнее, планированием ресурсов.

А еще точнее — по ситуации (научно — «ad hoc»). В екселе, на бумажке, по интуиции.

Проект-то, как мы помним, по своей природе хаотичен. А для хаоса нет и не может быть универсально-эффективных методологий.

Кто-то «предлагает»? На заборе тоже «предлагают». Сухой воды не бывает, дорогие товарищи, не тратьте жизнь и нервы на антинаучную ерунду.

С учетом уникальности каждого проекта (для данного предприятия), все равно тем и кончится.

5. Колоссальные «системы управления проектами», с нашей точки зрения, глубоко избыточны.

С одной стороны — они нерабочие со старта, ровно потому, что проект хаотичен.
Т.е. приведение некой монстрообразной «системы управления проектами» в состояние, адекватное нашему конкретному проекту, скорее всего будет дольше реализации последнего «на коленке».

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

Если таковые качественно работающие поставщики есть — мегасистема «управления проектом» ни к чему. Достаточно старой доброй диаграммы Ганта.

А если поставщики проекта — дрянь конторки, то оная мегасистема ничего и не поможет.
Если Вася забухал и кирпичи не привез, то сами понимаете: автоматические напоминалки по SMS положение вряд ли выправят.

6. Из вышесказанного можно предположить, что, хотя классические ERP-системы фундаментально не подходят для управления Предприятием, они теоретически могут быть полезны для управления проектами.

Так?

Нет.

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

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

Это системы планирования ресурсов. Они были спроектированы так, и развиваются (обойдемся без оценок) в этом направлении скоро полвека.

А как было показано выше, наилучшей системой планирования ресурсов проекта является сочетание удобной диаграммы Ганта и качественных поставщиков.

7. А откуда появляется Предприятие? Которое суть клубок процессов.

Из Проекта.

Имя которому — «стартап».

Каждый стартап (Проект — «куколка») на определенном этапе должен превратиться в бизнес (Процесс — «бабочка»).

Это крайне опасный момент, дорогие товарищи.

Если слишком рано (крайне редко, но бывает) — куколка перестает развиваться под тяжелым скелетом процессной организации. И погибает, не достигнув расцвета.

Если слишком поздно — хаотическая группа товарищей с идеями так и не осиливает выпустить на рынок промышленный продукт в серийном количестве с необходимым уровнем качества.

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

Хаотическая же группа товарищей остается свариться друг с другом, кто же «все проср#л».

8. СЕО бизнеса с амбициями обречен иметь дело как с Проектами, так и с Процессами.

Выше мы показали, как отделить одно от другого.

А теперь — главное: (всегда ограниченные) волевые и интеллектуальные ресурсы СЕО должны тратиться на Проекты.

Целью которых является такое изменение Процессов, чтобы последние работали автоматически.

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

Попытка наконтролировать три копейки с потерей заработка на миллиард.

Ergo, дорогие генеральные CEO-товарищи: занимайтесь Проектами, чтобы не заниматься Процессами.

«Сим победиши».

P.S. Но не забывайте — сии благотворные Проекты, равно как и операционный уровень бизнеса в целом, лишь половина труда настоящего IEM-лидера бизнеса.

Вторая половина — стратегический маркетинг.

Маркетинговая стратегия определяет потенциально доступный объем сбыта.

Качество реализации операционного уровня определяет % его достижения.

Отсюда:

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

А уже применительно к ситуации в данном бизнесе («ad hoc») компетентный СЕО определяет приоритетную точку приложения усилий.