К примеру, какое количество банковских сайтов отражают внутренние банковские процессы и системы, а не развитие ориентированного на блоггинг и развлечения Интернета, которым мы пользуемся сегодня? А какое количество банков предлагает онлайновое обслуживание для коммутируемого соединения по обычной телефонной линии, а не для широкополосного доступа? Таковы лишь два аспекта, которые станут движущими силами постоянного реинжиниринга бизнес-процессов в XXI веке. В конце концов, если не мы, то наши конкуренты сделают это.
Многие программы реинжиниринга десятилетней давности не «дожили» до своего завершения из-за череды сопутствующих обстоятельств того времени. В середине 1990-х многие банки всерьез занимались реинжинирингом бизнес-процессов, и как раз в тот момент, когда эти программы начали представлять заметный интерес (взять, к примеру, решение таких крупных проблем, как внутренняя политика и устаревшие системы), на горизонте замаячили внеочередные приоритеты вроде прихода евро и проблемы двухтысячного года. Затем мы переживали бурное развитие и спад Интернета, осваивали системы менеджмента взаимоотношений с клиентами [CRM]. Всевозможные модные управленческие концепции приходили и уходили, и вот, наконец, мы смогли перевести дух.
Сегодня перед нами все еще стоят большие проблемы, но теперь есть возможность спокойно разобраться в прошлом и определиться с желаемым будущим, потому что наши радары в кои-то веки не фиксируют крупных всплесков конъюнктуры, новых управленческих концепций или технологических «американских горок». Поэтому многие из нас возвращаются к самым основам и осознают, что наши бизнес-процессы все еще в полном беспорядке.
У нас по-прежнему множество изолированных подсистем и отделов, важничающих снобов, выполняющих узкоспециализированные бизнес-функции, и запутанных «макаронных» систем, которые служили цементом для старой структуры. Но самым большим отличием современного реинжиниринга является имеющаяся у нас возможность реконструировать каждый процесс от начала и до конца в масштабе всего предприятия, не разрушая и не ломая старые привычные способы ведения дел. Это означает, что мы можем трансформировать бизнес, не совершая революцию, — внедрять изменения в масштабе целого предприятия поэтапно и безболезненно, эволюционным путем. С помощью сервисоориентированной архитектуры путем внедрения постепенных изменений мы можем создать новое предприятие; благодаря методологии проектирования на основе компонентной структуры — прорабатывать отдельные элементы и постепенно «устанавливать» их на место; используя бизнес-планирование — строить предприятие по частям. Это главная отличительная черта сегодняшних программ реинжиниринга. А в результате мы придем к трансформации бизнеса.
Однако следует сделать одно предостережение касательно эволюции в сторону обновления предприятия: это не произойдет никогда, если управляющий состав банка — все руководство и генеральный директор в особенности — не примет участие в реализации программы. Основная часть крупных проектов по трансформации предприятия терпит неудачу. Как мы их ни назовем — BPR, TQM, CRM — четыре из пяти не достигают успеха. И большинство проектов обречено на провал по той причине, что реализация программы изменений поручается какому-то одному отделу. Подумайте над этим.
Давайте, к примеру, рассмотрим проект по совершенствованию работы с клиентами. Название может быть каким угодно — BPR, TQM, СЕМ — любая другая модная аббревиатура. Предположим, разработчиком проекта является начальник отдела обслуживания клиентов. Тогда проект становится головной болью его отдела, и именно он занимается реализацией проекта. Поскольку разработка и реализация программы целиком и полностью ложится на плечи работников отдела обслуживания клиентов, она не получает поддержки и участия отдела продаж, работники которого, однако, как выясняется, вынуждены выполнять в десять раз больше административной работы по поддержке программы. Если работники отдела продаж предварительно не введут в базу данных всю информацию о клиентах (что означает существенную прибавку к административным накладным расходам процесса продаж), работники отдела обслуживания клиентов не будут : располагать надлежащей информацией для выполнения своей части работы. Итог проекта легко предсказуем: провал.
Любой подобный проект требует поддержки как минимум со стороны всех функциональных руководителей. Поддержка означает полную самоотдачу и отношение к проекту как к своему собственному. Добиться этого можно только одним способом — ударив по кошельку участников проекта. Следовательно, чтобы гарантировать успех программы трансформации, необходимо материальное стимулирование через управленческие премии, комиссионные и зарплату. Тогда все члены команды будут кровно заинтересованы в успехе проекта. Однако добиться изменений в структуре материального поощрения руководящего состава можно лишь при поддержке и содействии генерального директора.
Генеральный директор находится на вершине банковской пирамиды, и это единственный человек, который в состоянии реализовать изменения в масштабе всего предприятия.
Функциональный руководитель может внедрить изменения в рамках своего подразделения, но не всего предприятия. Для реализации их на уровне компании необходимо участие и заинтересованность всех функциональных подразделений, а человек, в чьих руках находятся бразды правления всеми функциями, восседает на самой верхушке. Это генеральный директор. Но вот как раз здесь за все эти годы ничего не изменилось. В начале 1990-х годов четыре из пяти проектов терпели неудачу, потому что оказывались без непосредственной поддержки генерального директора, — ту же картину доводится наблюдать и сегодня. Все осталось по-старому, даже невзирая на революцию Интернета, невероятную скорость передачи данных, увеличившуюся за 20 лет на несколько световых лет, и чипы размером с кончик ногтя, быстродействие которых на порядок превышает возможности самого большого компьютера 1990 года.
Чтобы реализовать изменения на уровне предприятия, необходимо участие собственника, его поддержка, приверженность и самоотдача. Генеральный директор должен быть полон энтузиазма. От него требуется желание стать частью процесса перемен, оказывать практическую помощь и принимать активное участие. Генеральный директор должен жить программой перемен и дышать ею — он не может просто купить ее или поручить кому-то другому; он должен стать лидером программы трансформации предприятия.
Итак, если вы участвуете в программе, название которой содержит слова «предприятие» или «трансформация», удостоверьтесь в том, что человек, находящийся на вершине, считает программу своей собственной. Убедитесь в его желании получать ежедневные отчеты о ходе ее реализации и готовности бросить все остальные дела ради гарантированного успеха проекта. В противном случае лучше займитесь чем-нибудь более «эволюционным» на том уровне, который не выходит за рамки ваших функций.
Глава 7
Как оценить пользу технологии?
Руководитель подразделения Strategic Solutions компании Citigroup как-то раз признался мне, что финансовые модели, которые мы используем для обоснования инвестиций в информационные технологии, в корне ошибочны. Если вкратце, он сказал приблизительно следующее: «У нас множество чрезвычайно сложных финансовых моделей на основе рентабельности инвестиций [ROI), внутренней нормы доходности [IRR) и чистой приведенной стоимости [NPV], однако все они имеют значительный предел погрешности. По большому счету, мы действуем наугад». Неужели сегодня, в XXI веке, мы можем позволить себе принимать решения наобум, когда речь идет о многомиллионных инвестициях?
Я пришел в отрасль ИТ в 1980-х годах, полагая, что за технология-■ ми — будущее. (Кстати, сегодня будущее по-прежнему за ними.) В первые годы моей работы главной проблемой, с которой нам довелось столкнуться, было непонимание технологий пользователями: деловые круги в основной своей массе отличались пассивностью и отсутствием интереса к ним. В те времена от таких слов, как CICS, IMS, ASSEMBLER, FORTRAN и PASCAL, по спинам даже самых решительных компьютерных энтузиастов бегали мурашки.
В итоге мы пришли к бесконечному спору о том, почему бизнесмены не понимают ценности технологий и почему разработчики технологий не понимают потребностей бизнеса. Спор продолжается и поныне. Центральный вопрос касался того, кто же действительно полностью осознает ту пользу, которую может дать технология. И в то время ответ был однозначным: никто. Ни продавцы, ни разработчики технологий, ни отделы ИТ, и уж точно — не исполнительные директора, не генеральные директора и не деловые круги, для которых эта технология создавалась. Причина была очень простой. Первоначально технологии внедрялись потому, что они обеспечивали очевидные преимущества за счет автоматизации ручного труда: экономия за счет исключения рабочей силы из производственного процесса стала главным фокусом большинства компаний.
Поэтому на тот момент анализ экономической эффективности затрат не представлял особого труда. К примеру, если 10 служащих, занимающихся ведением счетов, обходятся компании в $ 25 тыс. на человека, но их можно заменить небольшим процессором для обработки данных стоимостью $ 300 тыс., то эти инвестиции окупятся менее чем через 18 месяцев.
Однако даже тогда все было не так просто. Я вспоминаю разговор с группой банкиров в середине 1990-х годов о технологии хранилищ данных. Они считали, что хранилища данных — слишком дорогое удовольствие. Поэтому я задал главный вопрос продавца: «Какую экономию обычно ваша система обеспечивает банку?» Ответ оказался весьма забавным. После десятиминутного молчания и последовавшей затем длительной консультации между генеральным директором и директором по маркетингу я услышал: «Мы не знаем». Они этого не знали, потому что никто не удосужился подсчитать сумму сэкономленных средств; они одобрили инвестиции, но впоследствии не измерили их рентабельность, поскольку вложенные деньги были уже списаны. В результате поставщику пришлось инвестировать немалые средства, чтобы подсчитать экономическую отдачу от поставляемых им решений. Звучит просто, но на самом деле измерить ценность решения очень сложно.