Скопировать ссылку
Недавно встречался со старым товарищем, работающим в управлении корпоративной архитектуры крупной нефтяной компании. Он жаловался, что ничего невозможно сделать разумного, доброго, вечного.
Описанная им ситуация типична для больших организаций:
- бизнес, пишет требования и перебрасывает их в ИТ;
- ИТ, в котором системные аналитики пытаются перевести язык бизнес-требований на язык ИТ-систем, чтобы программисты поняли что им делать;
- группа архитектуры, фактически играющая роль библиотекарей — описывают что в хозяйстве есть, для чего и как оно работает.
Чего не хватает в этом распределении ролей? По мне, тут просто зияющая пустота: отсутствует ключевая роль бизнес-технолога. (Это если говорить по сути, а фактическая должность может называться по-разному.)
Технологии есть и в производстве, и в офисе
Оглянемся на производство. Допустим, некая компания закупила производственную линию, смонтировала, запустила в эксплуатацию. Линия работает, выпускает продукцию. Можем мы себе представить ее работу в сколько-нибудь длительной перспективе без штатного технолога? Вряд ли. Меняется состав сырья, меняются комплектующие, меняется спецификация готовой продукции.
Немыслимо эксплуатировать производственное оборудование как черный ящик, надо все-таки понимать, как оно устроено и как его можно перенастроить. Для этого нужны специалисты, получившие как базовое техническое образование, так и, скорее всего, прошедшие курс обучения у производителя производственного оборудования. Сложная техника требует специалистов, это всем очевидно.
Теперь вернемся в офис корпорации (или в заводоуправление). Ведь это, по сути, тоже машина. Только не машина, выпускающая железки или брюки, я не знаю, — это машина, делающая деньги. И от того, как она спроектирована и отлажена, от того, насколько хорошо подогнаны друг к другу ее шестеренки — производство, логистика, финансы, маркетинг, продажи, сервис — зависит что в итоге у компании будет в строке прибыли-убытки. Ведь всем же понятно, что можно выпускать отличную продукцию, но при этом не уметь работать с клиентами и разориться. «А бывает и наоборот, и еще как бывает!» (цитирую классика).
ОК, называть "машиной" систему, состоящую из живых людей, некорректно по форме и не вполне правильно по существу. Другой мой товарищ любит говорить о своей компании как об общественном организме, и это пожалуй более правильно. Ведь машину из железа можно собрать по чертежам, включить, и она будет работать. Компания же больше похожа на живой организм — ее скорее выращивают, чем собирают.
Но давайте не придираться к словам — в конце концов, машины бывают разными. К примеру, если назвать хоккейную сборную "красной машиной" — это ведь никого не обидит, никого не низведет до положения "винтика"? Ну вот. Говоря "машина", я имею в виду разумность проекта и эффективность работы.
Управление проектами, управление процессами — это профессии
Что удивляет и удручает в современной российской практике, так это то, что в массе компаний либо вовсе отсутствует понимание необходимости проектировать слаженную работу подразделений в интересах общего результата, либо системная работа в этом направлении подменяется кустарщиной или имитацией.
Пример: крупный металлургический холдинг с периодичностью раз в два года проводит масштабный проект массового описания своих бизнес-процессов. Задача ставится так: "каждый должен описать свои бизнес-процессы". И несколько месяцев компанию лихорадит: менеджеры разного уровня описывают бизнес-процессы.
Но послушайте, "свой бизнес-процесс" — это же оксюморон! То, что мы делаем на своих рабочих местах — это функциональная компетенция; процессная же проблематика возникает на стыках между людьми и подразделениями. Кроме того, что проку описывать существующие процессы без анализа их эффективности, поиска узких мест и генерации идей по их расшивке? Да, порядка прибавится, но клиенты компании вряд ли заметят изменения к лучшему.
Без системного подхода, без взгляда на процесс как на кросс-функциональный и сквозной, "от и до", без постоянного стремления делать больше меньшими силами существенной пользы от такой активности не будет.
В ситуации, с которой я начал, мы видим: с одной стороны, прагматичные менеджеры разных уровней, каждый из которых должен давать результат "здесь и сейчас" и которого волнуют только показатели своего отдела или департамента. Бизнес-процесс "от и до", интересы клиента — это для них какая-то неведомая абстракция. С другой стороны — ИТ-специалисты, которые могут автоматизировать все что угодно, но плохо понимают потребности клиентов, глубинные интересы и проблемы различных служб внутри компании и противоречия между ними.
Ни те, ни другие объективно не способны подходить к решению проблем системно, т.е. не "по месту", а продуманно; не сиюминутно, а на перспективу; не на уровне своего подразделения, а на уровне сквозного "от и до" бизнес-процесса; не создавая зону комфорта для себя, а учитывая интересы клиента.
Для этого нужны специально обученные люди — профессионалы в области проектного управления и/или процессного управления, в зависимости от того, преобладает ли у вас деятельность проектная (нацеленная на получение уникального результата) или процессная (массовая, повторяющаяся). И отдельное подразделение, в котором необходимая компетенция будет накапливаться и развиваться. Зачем нужен отдел главного технолога — понятно? Точно так же своя организационная ячейка должна быть и у бизнес-технологов.
Причем у проектных организаций дело в среднем обстоит лучше: что есть такая профессия "менеджер проекта" всем понятно, и что на каком-то этапе развития компании понадобится проектный офис — тоже.
Передовой опыт процессных организаций
В области же управления процессами осознание только-только начинается. Уже есть международная Ассоциация профессионалов управления бизнес-процессами с отделением в России, переведен на русский язык Свод знаний по управлению бизнес-процессами (BPM CBOK), обсуждается и скоро будет принят профессиональный стандарт "Специалист по управлению процессами", но в оргструктуре компаний редко увидишь Центр компетенции BPM или Процессный офис. Там же, где они есть, зачастую дело подменяется имитацией: бесконечные описания бизнес-процессов в стол или сертификация по ISO 9000 для галочки.
Относительно хорошо дело обстоит в финансовой отрасли. Например, стандартным элементом оргструктуры в банках является Департамент банковских технологий. Это ведь они и есть — люди, находящиеся между бизнес-операциями и ИТ и по должности обязанные (и обученные!) думать и действовать системно. Банки оказались впереди, потому что у них нет выбора: ведь в случае банка продукт равняется процессу. В самом деле, что означает "банк X предложил рынку новый банковский продукт Y"? Именно то и означает, что банк спроектировал и внедрил бизнес-процесс, реализующий продукт Y.
Этот опыт стоило бы взять на вооружение всем крупным организациям.
Под крупными в данном случае понимаются те, которые могут себе позволить содержать штат специалистов по бизнес-процессам и корпоративных архитекторов. В компании среднего масштаба (условно, до тысячи сотрудников) такой человек может быть один, но он должен быть. В компании численностью до ста сотрудников роль бизнес-технолога зачастую выполняет кто-то из высшего руководства — финансовый или технический директор, сам генеральный или его ближайший помощник.
Функцией структуры, о которой мы говорим, должно быть проектирование бизнес-процессов, начиная с основных, и дальнейшее сопровождение их по всему жизненному циклу: мониторинг, измерение показателей, внесение как небольших улучшающих, так и значительных революционных изменений.
Для справки: основными принято называть бизнес-процессы, непосредственно отражающиеся на потребителях — разработка новой продукции, продвижение продукции и услуг, предпродажная активность, выполнение договорных обязательств, пост-продажный сервис. Помимо этого, выделяют процессы вспомогательные — они обеспечивают основные необходимыми ресурсами: финансами, персоналом, сырьем и материалом, станками и сооружениями и т.д. Третья группа — процессы управления, такие как инициализация проекта или актуализация стратегии организации.
Название организационной единицы тоже имеет значение. По мнению автора, название «Департамент бизнес-технологий» наиболее точно обозначает ее сферу деятельности и ответственность. Если вместо этого вы создадите СМК (службу менеджмента качества), то получите на выходе тысячи инструкций и сертификацию по ISO 9000, и только. "Процессный офис" ассоциируется с канцелярией; "Центр компетенции" звучит неплохо, но просто быть умным недостаточно — надо что-то делать, за что-то отвечать.
Без профессионального отношения к бизнес-процессам вы рискуете остаться с процессами кустарными, устаревшими, неповоротливыми (намертво зашитыми в ERP-систему), страдающими болячками субоптимизации. А с ними в современном быстро меняющемся мире на успех рассчитывать трудно.
Меня, как лицо заинтересованное, ваша оценка 5-10 лет не радует :( Тем более, что как делается - понятно уже сейчас. Думаю, проникновение "цифры" - появление цифровых моделей бизнеса - ускорит осознание необходимости системной работы.
Единственный мой более-менее успешный опыт, когда мы внедряли Единую Информационную Систему в банке с 30-ю филиалами, где до того всё делалося на коленках, у всех свои проги, от 1С до Эксель и прочее.
Собрали всех: директоров филиалов, разработчиков и представителей Руководства в одном пансионате в Подмосковье, всех подружили, и не выпускали, пока они не договорились.
Мораль (по личному опыту): сейчас все акценты делаются на бизнес-процессы софтину, чем круче - тем лучше.
А на самом деле ключ - пресловутый Человеческий Фактор (Мать Его За Ногу):(((
Это очень грустно наблюдать, поскольку я уверена, что в хорошем тандеме с бизнес-заказчиком аналитик/технолог даже не самого высокого уровня подготовки может значительно повысить эффективность работы системы.
Еще одна большая беда, которую лично я замечаю, - отсутствие и у самих бизнес-технологов, и у hr-ов, и у топ-менеджмента понимания, что такое бизнес-технолог и какими компетенциями он должен обладать. На выходе имеем мешанину из системного-бизнес-тестировщика с умением сделать и бизнес-процесс, и базу данных в равной степени, и заодно фин.анализ провести, потому что почему бы и нет, "ты же аналитик".
Поэтому читать о том, как важен бизнес-технолог для российского бизнеса, конечно, приятно, и статья замечательная, но пока что это мало применяется в действительности, с которой постоянно приходится сталкиваться.