Нужна ли централизация

Один из возможных подходов к автоматизации процессов состоит в создании громадного монолитного приложения, решающего все поставленные задачи, — это подход «одной большой программы». Однажды мы испробовали его на практике — когда попытались написать единое приложение приема и выполнения заказов для целой дюжины своих вспомогательных подразделений: библиотеки, службы безопасности, столовой, отдела бронирования билетов и гостиниц, магазина, отдела корпоративных кредитных карточек и др. В конечном итоге этот проект оказался в числе немногих, которые пришлось свернуть. Потребности различных служб были слишком разнообразными, и бизнес-правила получались слишком сложными для обработки одним приложением. На доведение системы до рабочего состояния ушло столько времени, что, когда она была готова, требования пользователей успели уже измениться. Из этой истории мы вынесли один важный урок: лишь очень немногие приложения, предназначенные для корпоративного применения, требуют «центральной» точки зрения. После такой неудачной попытки каждой группе была предоставлена возможность самостоятельно построить собственную систему обработки заказов. Уменьшение масштаба значительно упростило задачу и сократило время разработки. Сегодня все вспомогательные подразделения пользуются собственными программами учета заказов. Каждые несколько месяцев в эти приложения вносятся те или иные усовершенствования, и любое из них может служить великолепным примером безбумажного процесса, экономящего время и упрощающего контроль за предоставлением высококачественных услуг.

Мы стараемся избегать длительных циклов разработки приложений, предназначенных для внутреннего использования. Слишком продолжительные сроки часто сводят к нулю преимущества, поскольку потребности бизнеса постоянно меняются. Компактные децентрализованные процессы обычно решают задачи лучше всего. Лишь очень немногие приложения, такие, как система составления финансовых отчетов, действительно требуют централизации. Работая над решением других внутренних задач, мы всегда старались обходиться небольшими проектами с минимальным числом участников, держа в уме лозунг наших групп разработки коммерческого ПО: «Дата поставки — это одно из существенных свойств продукта».

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

Список ключевых приложений включает в себя программу корпоративных закупок MS Market, работающую в нашей интрасети; частный узел Интернета, или узел «экстрасети», MS Invoice, через который присылают нам счета агентства, поставляющие временных работников, и другие партнеры; а также ПО фирмы SAP, обслуживающее все наши финансовые транзакции. Поскольку программа HeadTrax, предназначенная как раз для автоматизации кадровой работы, находилась к тому времени уже в промышленной эксплуатации, мы использовали ее интерфейс, к которому «с обратной стороны» подключались различные другие модули. Пользователю достаточно активизировать определенную функцию из HeadTrax, a нужное внешнее приложение запускается автоматически.

Процесс заключения трудового договора начинается с электронного оформления требования на закупку (в данном случае рабочей силы) в приложении MS Market, которое подробно описано в главе 3. Операции создания регистрационных записей временных работников, их найма и администрирования очень похожи на те, что предусмотрены в HeadTrax для штатных сотрудников. Программа MS Invoice обеспечивает прием счетов в электронной форме и позволяет как нанимающему менеджеру, так и агентству по найму контролировать исполнение бюджета. По получении каждого счета нанимающий менеджер может проверить, сколько еще денег остается (и остается ли) на счету соответствующего заказа. А агентства по найму сверяют с помощью системы полученные суммы с выставленными счетами. Если попытаться выставить счет на сумму, превышающую остаток по соответствующему заказу, он не будет принят. Если же агентство решит повысить ставку своего работника, менеджеру Microsoft достаточно одного нажатия на кнопку мыши, чтобы утвердить или отвергнуть это изменение в контракте.

У вдумчивого читателя может возникнуть вопрос, а зачем нам вообще нужны все эти счета, электронные или нет? В конце концов, ведь удалось же лидерам ряда производственных отраслей исключить их из своего документооборота. Классическим примером может служить корпорация Ford, обходящаяся без счетов при закупке комплектующих. Когда партия запасных частей поступает на склад, приемщик просто вводит в электронную систему сообщение об этом, и механизм перечисления платежа поставщику запускается автоматически. Производитель получил комплектующие, а поставщик — деньги. Кому нужны счета — хотя бы даже и электронные?

Мы поэкспериментировали с этим подходом, однако натолкнулись на ряд сложностей, обусловленных отличиями услуг от товаров. В производстве каждый компонент имеет свой инвентарный номер. А при получении «рабочих часов» временного участника проекта организовать их учет аналогичным образом оказывается не так просто. Агентству, из которого он пришел, необходимо ассоциировать каждый полученный платеж со своим конкретным работником и конкретной рабочей неделей, что очень непросто сделать, не пользуясь такой справкой, как выставленный и оплаченный счет. Создание системы платежей без выставления счетов, которая устраивала бы наших поставщиков, остается пока делом будущего. Уже и создание полностью электронного процесса документирования работы временных сотрудников, позволяющего легко получать доступ ко всей необходимой информации в любое время, потребовало от нас значительных усилий.

Плохо организованный процесс администрирования потребляет вдесятеро больше времени, чем сама работа, — это азбучная истина. В литературе можно найти множество примеров того, как в результате реинжиниринга продолжительность тридцатидневного цикла удавалось сократить до трех дней или десятидневного — до одного дня. Хорошо организованный процесс не допускает пустой траты времени, а технологические достижения повышают производительность труда при выполнении реальной работы. Наше новое ПО автоматизации документооборота, связанного с привлечением временных сотрудников, тоже должно повысить скорость процесса, но это усовершенствование будет не самым главным. Для бизнеса намного важнее повышение качества надзора за процессом заключения контрактов с временными работниками со стороны высшего руководства и гарантия соблюдения всеми утвержденных правил. И даже еще более важно то, что мы получим возможность вести учет качества выполненной работы от контракта к контракту и строить свои отношения с конкретными людьми на этой основе.