А еще лучше - сверьтесь с нашими рекомендациями.
Пилотный проект, которым руководила Кэрол Шилат, потерпел фиаско. И именно это обеспечило ему успех. Система составления заказов и формирования прогнозов через Internet, которую Шилат разрабатывала для компании Heineken USA, должна была хотя бы немного сократить восьминедельный срок доставки пива дистрибьюторам. Полгода обкатки новой системы у дистрибьюторов из штата Флорида показали, что время доставки пива... почти не изменилось. Так почему же Шилат осталась довольна?
 |
| Директор по информационным системам компании PeopleSoft Джим Александер и менеджер по процессам Венди Спосато уверены, что добиться высоких результатов позволила система премирования сотрудников проектной группы, установивших наиболее плотную обратную связь |
«Сейчас мы работаем над проектом обеспечения цепочек поставок между Heineken Netherlands, Heineken Export и Heineken USA в рамках единой системы», — рассказывает Шилат, являющаяся директором по информационным технологиям в компании White Plains. «Не думаю, что мы бы смогли это делать, не имея опыта, полученного в ходе проекта HOPS». Сейчас 450 дистрибьюторов Heineken в США пользуются системой HOPS в качестве единого и хорошо зарекомендовавшего себя средства для выполнения бизнес-операций.
Очень важно, что в данном случае относительно небольшой и дешевый эксперимент в рамках дочерней фирмы стал уроком стратегического значения. А ведь подобные уроки могла бы извлечь для себя любая компания, относись она к пилотным проектам как к «окну в будущее», а не как к способу проведения жестко контролируемой обкатки нового ПО.
 |
| Кэрол Шилат, директор по ИТ компании Heineken USA, руководила пилотным проектом, в котором попытки решения тактических проблем привели к стратегическим решениям |
Мыслите масштабно. Люди типа Шилат поняли, что скромный маленький пилотный проект может заключать в себе очень много амбиций — и одновременно риска. Однако это тот самый риск, на который компании обязаны идти ради поддержания конкурентоспособности. Вспомните, как в начале 90-х многие заказчики «клюнули» на возможности ERP-систем по автоматизации основных бизнес-процессов, не оценив при этом возможного влияния этих огромных и сложных программных пакетов на работу сотрудников и на компьютерную инфраструктуру. В результате появилось море историй о том, как компании так и не смогли заставить это ПО нормально работать и после двух-трех лет усилий сворачивали проект, одновременно прощаясь с инвестициями в десятки миллионов долларов. Пилотные проекты — незаменимая вещь при оценке возможных негативных последствий от внедрения ПО масштаба предприятия и от изменения бизнес-процессов.
Десять примеров, приводимых ниже в этой статье, — это десять озарений капитанов рискованных пилотных «экспедиций», завершившихся благополучно.
Поймите, все ли вы взяли от старого, прежде чем браться за новое. Нужно наложить табу на начало новой деятельности, пока нет полного понимания уже существующих процессов. Иначе новые процессы могут перенаправить ваши усилия на решение несуществующих проблем.
 |
| Пытаясь ускорить процесс обработки заявок на выставление счетов для брокеров компании Amex, президент фирмы Digital Agility Дебора Кэшин обнаружила, что быстрый ввод документа в компьютер может оказаться хуже, чем отсутствие ввода вообще |
«Пилотная команда» без раздумий взялась за электронное решение проблемы. Она посчитала, что дела пойдут более гладко, если заявки сканировать и вводить в компьютерную систему управления документами сразу по прибытии в комнату для разбора почты и затем передавать документы дальше опять-таки в электронном виде. Однако, к счастью, техническая команда под руководством президента консалтинговой компании Digital Agility Деборы Кэшин нашла время побеседовать со всеми участниками процесса обработки заявок и пронаблюдать, как все происходит.
Выяснилось, что на начальной стадии обработки содержимое заявки никого не интересовало; требовалось всего лишь знать ее местонахождение. А новое приложение, рассчитанное на файлы большого размера, запросто «посадило» бы сеть. Чтобы представитель бухгалтерии мог знать, поступила ли ожидавшаяся заявка и к какому сроку ее нужно обработать, достаточно было только зарегистрировать заявку, но не заносить ее в систему целиком.
 |
| Когда продавцы, работающие с компанией Siemens, затруднялись вспомнить, как работать с новой системой ведения продаж, руководитель проекта внедрения новой системы Сьюзен Дейл делала вывод: программа устроена чересчур сложно |
Сканирование решили перенести на следующую фазу выполнения процесса, когда требовалась уже реальная работа с содержимым заявки. Вот так хорошие навыки ведения пилотных проектов (а именно стремление понять бизнес-процесс, прежде чем предлагать решение) позволили Кэшин и ее товарищам избежать катастрофы.
Подпишите договор о выполнении проекта и всех с ним ознакомьте. Команда Кэшин подготовила договор, где четко определила рамки и задачи пилотного проекта. «Все получили общее представление о том, что собой будет представлять система делопроизводства и как она повлияет на жизнь сотрудников», — рассказывает Кэшин. Однако если за рамками этого документа остаются более частные задачи, люди могут разочароваться из-за того, что их ожидания не учтены в новой системе. По словам Кэшин, некоторых сотрудников не оставляла надежда, что их участок делопроизводства будет автоматизирован даже несмотря на то, что он явно не был включен в рамки проекта.
Теперь Кэшин понимает недостатки того договора. «Он был составлен в расчете только на некоторых лиц из числа менеджеров, а обычный народ не понимал, о чем там шла речь, — вспоминает она. — Составление договора требует участия самой широкой аудитории путем организации собраний сотрудников и проведения совещаний у руководителя проекта. Мы собирались устроить презентацию пилотного проекта каждой группе сотрудников, которой он должен был коснуться, чтобы рассказать людям, чего им следовало ожидать от проекта, а чего нет. Но у нас не хватило на это времени, и я об этом сожалею».
Отберите в свою пилотную группу самых лучших и сообразительных сотрудников. Небольшое и не основное подразделение, не вовлеченное в ключевое направление деятельности компании, нельзя считать подходящей площадкой для обкатки нового ПО и новых процессов, если планируется их использование всеми сотрудниками компании. «Демонстрируйте всем, что к проверке подключено достаточное количество самых разных людей и что результаты проекта не ограничены одной небольшой замкнутой производственной нишей», — рекомендует Карл Фраппаоло, исполнительный вице-президент Delphi Group. Важно также, чтобы размер подразделения и объем выполняемых им операций соответствовали масштабу проекта. Бизнес-подразделение, в котором планируется начать пилотный проект, должно быть значимым, важным и нужным всей компании и иметь в своем штате уважаемых всеми людей. Работая с компанией Amex, Кэшин выбрала для этой роли брокерское подразделение потому, что это было быстрорастущее звено, в прошлом обойденное вниманием отдела ИС. Для группы сотрудников подразделения менялся на глазах сам их бизнес — брокерские услуги, и люди хотели перемен.
Если для реализации проекта ни одна «готовая» группа по каким-либо соображениям не подходит, некоторые компании пробуют набирать для участия в проекте представителей из разных подразделений, которых коснется проект. В калифорнийском офисе Siemens Information и в подразделении корпоративных систем (END) компании Communications Network группа по реализации пилотного проекта обратилась ко всем вице-президентам региональных торговых организаций подразделения с просьбой выбрать в своих группах лидеров — людей, умеющих хорошо продавать, для участия в проекте по испытанию нового ПО для автоматизации продаж. Целью проекта было повышение эффективности процесса продаж путем автоматизации передачи данных о наиболее активно продаваемых видах продукции из центров сбора телефонных звонков в отделе маркетинга (там эти данные формировались) продавцам на местах. Ранее этот процесс базировался на передаче телефонограмм, диктовавшихся с наспех составленных от руки записок. Цель проекта была воспринята в штыки: торговые представители из отделения внутринациональных расчетов END бойкотировали попытки автоматизации, ощущая себя вполне комфортно наедине со своими ежедневниками и шариковыми ручками. Команда разработчиков проекта обратилась к региональным вице-президентам, чтобы те уговорили своих людей начать пользоваться компьютерными программами.
Начните с малого, будьте осторожны и осмотрительны в своих действиях. Пилотный проект по делопроизводству должен был охватить в конечном счете 300 сотрудников, однако Кэшин сначала установила ПО на машинах 12 сотрудников, и те начали с ним работать. Спустя две недели она стала постепенно вовлекать в проект все больше и больше людей. Медленный старт дал возможность убедиться в отсутствии серьезных проблем после окончания работ по планированию, обсуждению проекта и разработке ПО. «Мы хотели услышать от пользователей: ??Да, мы видим, на что способна новая система, и она в самом деле делает то, ради чего создавалась??», — говорит Кэшин.
Поэтапное развертывание системы позволило Кэшин держать под контролем накатывающиеся волны проблем и встречных предложений, которые, как она ожидала, должны были появиться при использовании системы непосредственно в рабочем процессе. В Siemens поступили аналогично, поначалу установив новую систему 45 сотрудникам отдела автоматизации из 450. Здесь, скорее, важны не относительные, а абсолютные показатели. Руководители пилотных проектов полагают, что вовлечение в пилотный проект более чем 40-60 пользователей может существенно усложнить его реализацию.
Тактика «малой группы» позволила Кэшин избежать больших проблем и направить реакцию остальных участников проекта в русло предложений по его улучшению, а не поиска ошибок. Борьба с ошибками в масштабах всей компании наверняка бы негативно отразилась на ходе реализации проекта.
Помните, что вы работаете не в вакууме. Пытаясь самостоятельно улучшить процесс, основное узкое место которого находится где-то вовне, вы напрасно тратите силы. Об этом свидетельствует случай с командой Кэшин: когда они с помощью новой системы организации подачи заявок на выставление счета начали бороться с кипами бумаг, то обнаружили, что тормозом для них стали правила Национальной ассоциации торговцев ценными бумагами (NASD). NASD требует, чтобы новые счета подписывал финансовый руководитель высокого ранга. Следовательно, Кэшин должна была параллельно с новой «электронной» цепочкой прохождения документа обеспечить и перемещение первоначальной заявки в бумажном виде только ради того, чтобы она была подписана.
Как и в случае с Шилат, обратившейся за решением своих проблем в Голландию, Кэшин выступила с предложением к NASD ввести в практику электронную подпись документа. После этого потребовалось создать дополнительную «линию защиты» и ввести пароли, позволяющие иметь доступ к заявкам и скреплять их электронной подписью только определенным руководителям. Все остались довольны: Amex последовала пожеланиям NASD и покончила с бумажной гонкой.
Проверяйте все, в том числе самые обычные персоналки. В большинстве отделов ИС понимают необходимость моделировать влияние на сеть дополнительных нагрузок от нового ПО (для этого имеется целый ряд специальных программ) и проверять его на совместимость с сетевым ПО. Однако во многих ИТ-подразделениях пренебрегают проверками работоспособности нового ПО на компьютерах реальных пользователей. В Amex команда Кэшин устроила специальные лабораторные испытания и убедилась, что на всех видах компьютеров, имеющихся в распоряжении пользователей, новое ПО совместимо с тем, что уже есть на этих машинах. В проекте HOPS примерно через шесть месяцев после начала работ сервер пришлось полностью модернизировать из-за недостаточно быстрой работы прикладной системы.
Обратная связь — хорошо, а своевременная обратная связь — лучше. Одним из главных преимуществ пилотного тестирования процессов и прикладных систем является возможность их оперативного изменения. В пилотном проекте по внедрению новой системы автоматизации продаж в фирме Siemens команда, руководимая Сьюзен Дейл, менеджером по автоматизации продаж, пошла на такой прием: они разместили на экранах компьютеров специальную кнопку, нажав которую участник имел возможность поделиться своим предложением или мнением. Иногда комментарии звучали примерно так: «Я не помню, что вы мне говорили по поводу того, как этим пользоваться». Или так: «Тут что-то очень сложно, я этого не понимаю». «Мы решили, что если люди чего-то не могли запомнить из месяца в месяц, то это место в системе и в самом деле устроено слишком сложно», — вспоминает Дейл и добавляет, что такого рода обучение происходит лишь при условии, если пользователи новой системы пытаются с ее помощью выполнять свою основную работу.
Обзаведитесь «парашютами» для своего пилотного проекта — так, на всякий случай. Когда Шилат предложила проект HOPS клиентам Heineken USA, против нее работало два фактора. Первый заключался в привычном комфорте старого способа составления заказов: чтобы прикинуть, сколько новых типов пива следует заказать и для каких видов пива нужны специальные меры по продвижению на рынок, нужно было посидеть и поговорить с местным представителем Heineken, затем отослать заявку и ждать, когда из Голландии придет нужный контейнер Heineken. Отучать пользователей системы от такого расточительного по времени, но приятного метода работы было непросто, даже учитывая все достоинства продвигаемых новшеств.
Heineken тем временем не прощалась и со своим старым процессом составления заказов. Хотя компания и не поощряла специально использование факсовых аппаратов, простое осознание такой возможности для подстраховки вселяло в людей чувство спокойствия на этапе испытаний новой системы. «Поначалу все искали обходных путей», — вспоминает Фрэнк Фюрст, разработчик и консультант, президент компании B2B Technologies, помогавшей Heineken разрабатывать систему. «В первый месяц едва ли не все сотрудники, сделав заказ через компьютер, дублировали его по факсу, — рассказывает Фюрст. — Но уже на втором месяце большинство пользовалось исключительно компьютерной системой».
Дайте своим испытателям почувствовать себя в привилегированном положении. В ходе реализации проекта HOPS ни одно требование компаний-дистрьбюторов не считалось ни излишне завышенным, ни слишком мелким. «Чтобы приучить пользователя к Internet, мы по всякому поводу высылали во Флориду группу из двух-трех наших специалистов, — говорит Шилат. — Мы даже делали вещи, совершенно не связанные с проектом, например тестировали их ПК».