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

И ещё было бы неплохо постоянно уделять внимание оптимизации процессов.

Какое-то слишком сильное обобщение, Вам не кажется? Я могу судить про бизнесы размером до 20 человек, порядка 5000 человек и в промежутке между ними. Так вот, именно те, что в промежутке, как раз могут похвастаться своей выдающейся негуманностью.

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

В крупном бизнесе не знаешь никого в лицо, процессы везде и всюду, но там нарабатывается достаточно прибыли, чтобы доходили руки внедрить процессы и для самого нижнего уровня иерархии, которые там, внизу, окончательно становятся инструментами. Например, инструмент “формуляр HW-08″ можно применить, чтобы пришли, забрали старый и выдали новый компьютер. В итоге исполнители не только много работают НА процесс, но и могут сами воспользоваться процессами.

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

А те процессы, которые в среднем бизнесе уже есть, они зачастую такого качества, что лучше бы их и не было. У нас, к примеру, с самого верха спустили Team Foundation Server. Те, кто спускал, ни секунды с этой системой не работали и не работают, и решение приняли из соображений, которые мне до сих пор не ясны. Как система контроля версий оно еще неплохо (хотя есть и сильно лучшие системы, но к сожалению не в мэйнстриме). А вот как баг трэкинговая система, это просто шняга. Любая, даже бесплатная веб-прилада типа багзиллы покроет в этом смысле TFS как бык овцу. Не говоря уже о Jira или Mantis. В результате могу наблюдать, что группы в фирме либо баги по нормальному не отслеживают, либо стабильно проваливают проект за проектом, работая строго “по процессу”. Ну и кому такой “процесс” помог? Конкретно тому менеджеру, что ввел эту систему. Его повысили и сделали совладельцем фирмы. Впрочем, про карьеры плохих менеджеров Вы тоже уже написали Мне бы и не жалко, если бы не приходилось сидеть по уши в отходах их жизнедеятельности.

Ничего, я тоже в более новое ничего не игрался.

Как вы точно заметили, с краном все поопаснее, поэтому тоже так не выйдет.

В софте, можно только в коде undo сделать. А вот в бизнесе undo не сделаешь, просранные деньги и заваленный проект не “откатишь” назад.

>Что касается загонять или не загонять. По-моему, процесс, в который нужно загонять, просто >не верен. Это такой верный признак, как синтаксическая ошибка в коде. Такой процесс и >после успешного “загона” прибыли не принесет.

Это _НЕ_ правильная идея.
Я писал вот тут: http://victorronin.com/2008/07/15/biznes-eto-vam-ne-xixanki-xaxanki/

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

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

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

Работа может быть чем угодно.

Бизнес – это метод получения денег. Очень здорово, если это сопровождается весельем. Чаще это сопровождается рутиной.

>Потому что есть более веселые процессы, тот же Scrum или MSF.

Скрум тоже является процессом. Причем в нем тоже есть железные вещи и вещи, которые более мягкие.

Насчет “веселые процессы”. Как я и писал, если не уменьшая веселость бизнес будет получать свою прибыль – такие процессы используют. Если веселость вдруг уменьшает прибыль, то веселость порубят.

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

Если Scrum весел для одних, это еще не значит, что он весел для других. Идеального для всех процесса не бывает.

Чаще всего владельцы (кроме lifestyle business) пытаются настроить так, чтобы оно максимизировало именно прибыль.

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

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

Что касается загонять или не загонять. По-моему, процесс, в который нужно загонять, просто не верен. Это такой верный признак, как синтаксическая ошибка в коде. Такой процесс и после успешного “загона” прибыли не принесет.

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

Потому что есть более веселые процессы, тот же Scrum или MSF. Где каждое дисциплинарное ограничение тщательно обосновывается, а все, что можно, вынесено “на свое усмотрение”.

а) Насчет плавного перехода.

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

Поэтому, все же стоит говорить о связи инструментов и процессов.

б) Насчет того, что процесс – является инструментом. Так оно и есть, процесс это всего лишь
определенный инструмент.

Насчет загоняния работаь в команде с неприятным человеком. Если вероятность вашего ухода умноженная на потенциальные потери от вашего ухода меньше, чем дополнительная полученная прибыль/часть рынка и т.п. То в общем-то менеджеру или владельцу в конечном счете может быть и все равно.

Вопрос можно ли было вас не загонять? Возможно и можно было, это надо в каждой ситуации смотреть. Хотя опять же, если не загоняние вас займет больше времени и ресурсов, чем дополнительная работоспособность от вас полученая, то опять же, смысла НЕ загонять – не будет.