Более того, бумажный процесс не позволял высшему руководству адекватно решать бюджетную проблему. Поскольку, с одной стороны, временную рабочую силу использовали многие отделы, а с другой, временные работники нередко участвовали каждый в нескольких проектах сразу, главе подразделения оказывалось трудно подсчитать общее число таких сотрудников или отработанных ими часов. Было невозможно дать сколько-нибудь надежный прогноз расходов на оплату их труда. Отчетные данные по числу работников и их выработке в часах и в денежном выражении, которые старшие менеджеры получали от финансовых отделов, всегда запаздывали; а более оперативно можно было получить лишь приблизительные оценки. Размеры выплат испытывали резкие колебания от месяца к месяцу.
Сначала мы думали, что проблема коренится в организации работы финансовых отделов, но, проанализировав имеющуюся информацию, поняли, что они просто плохо обеспечены исходными данными. Наш процесс оплаты труда имел слишком мало управляемых параметров. Несмотря на большое число виз — менеджеры подписывали карточки учета отработанных временными работниками часов, те представляли их в свои агентства, агентства же выставляли счета отделу снабжения, который их оплачивал, — какие-либо финансовые рычаги управления фактически полностью отсутствовали. По полученному от агентства счету менеджер не мог проверить ни почасовую ставку, ни количество отработанных часов. Более того, счет мог быть выставлен даже в отсутствие подписанной карточки учета часов. Или нанимающий менеджер соглашался на повышение почасовой ставки, а до специалистов, занимающихся оформлением временных работников, эта информация вовремя не доходила. Или ставка повышалась по одному из проектов, а оплата по ошибке увеличивалась и по всем остальным. Не существовало и никакого способа предотвратить повторное выставление счетов за одну и ту же работу.
«Поднявшись над процессом», мы изучили его от начала и до конца и рассмотрели возможности его упрощения с помощью электронного информационного инструментария.
Одна из проблем с администрированием заключалась в том, чтобы решить, следует ли предоставлять менеджерам, нуждающимся во временных работниках, полномочия самостоятельно их нанимать. При использовании старого бумажного процесса не было никакого способа пересмотреть однажды принятое решение о привлечении дополнительных ресурсов. Подписав представление о найме временного работника, менеджер даже не мог проверить, соответствуют его дальнейшие действия установленным правилам или нет. Например, достаточно ли в бюджете средств для оплаты этой дополнительной работы? Следует ли разрешить оплату сверхурочных по данному проекту? Кроме того, руководителю, нуждающемуся во временной рабочей силе, было очень непросто составить себе представление о том, какая почасовая ставка будет адекватна предполагаемым обязанностям нового сотрудника и как подойти к подбору квалифицированного исполнителя для них. Не имея на примете конкретного работника, было нелегко решить даже вопрос о том, где его искать — обратиться в какую-либо компанию, в агентство или же найти независимого специалиста? Нам необходим был некий способ, позволяющий заранее автоматически рассчитывать полную сумму расходов, чтобы закладывать ее в бюджет.
Было решено, что для этого требуется гибкое программное решение. Оно должно было гарантировать составление и подписание контракта с каждым временным работником еще до того, как он приступит к исполнению своих обязанностей. По заключении контракта для него в течение 48 часов должны были подготавливаться пластиковая карточка для прохода через турникеты системы безопасности, внутренний телефонный номер и учетная запись доступа в корпоративную сеть. Система должна была позволять легко создавать сразу несколько идентичных запросов на однотипные вакансии, что весьма типично для крупных проектов. В процессе исполнения контракта менеджер должен был иметь возможность легко проверить число отработанных часов, ставку и остаток денег, выделенных на оплату по нему в течение всего проекта или этапа. С приближением даты окончания контракта соответствующему нанимающему менеджеру должно было автоматически выдаваться соответствующее уведомление и предоставляться возможность продлить данный контракт, но только при условии, что в бюджете остается достаточно средств и что время, уже отработанное данным работником на Microsoft без перерывов, не превышает 340 дней. С окончанием срока контракта доступ к корпоративной компьютерной сети и в здания компании должен был автоматически закрываться, а адрес электронной почты и телефонный номер — освобождаться.
Кроме того, новый процесс ни при каких обстоятельствах не должен был создавать задержек в работе. Если руководитель, в чью компетенцию входит утверждение контрактов, оказывался в нужный момент недоступен, нанимающий менеджер должен был иметь возможность получить подпись от другого человека, обладающего необходимыми полномочиями. В случае перевода контракта в ведение другого менеджера или другого учетно-калькуляционного подразделения не должно было возникать сложностей с перераспределением издержек. Агентствам предоставлялось право самостоятельно повышать ставку временного работника в небольших пределах, но крупное повышение требовало визы нанимающего менеджера.
НУЖНА ЛИ ЦЕНТРАЛИЗАЦИЯ
Один из возможных подходов к автоматизации процессов состоит в создании громадного монолитного приложения, решающего все поставленные задачи, — это подход «одной большой программы». Однажды мы испробовали его на практике — когда попытались написать единое приложение приема и выполнения заказов для целой дюжины своих вспомогательных подразделений: библиотеки, службы безопасности, столовой, отдела бронирования билетов и гостиниц, магазина, отдела корпоративных кредитных карточек и др. В конечном итоге этот проект оказался в числе немногих, которые пришлось свернуть. Потребности различных служб были слишком разнообразными, и бизнес-правила получались слишком сложными для обработки одним приложением. На доведение системы до рабочего состояния ушло столько времени, что, когда она была готова, требования пользователей успели уже измениться. Из этой истории мы вынесли один важный урок: лишь очень немногие приложения, предназначенные для корпоративного применения, требуют «центральной» точки зрения. После такой неудачной попытки каждой группе была предоставлена возможность самостоятельно построить собственную систему обработки заказов. Уменьшение масштаба значительно упростило задачу и сократило время разработки. Сегодня все вспомогательные подразделения пользуются собственными программами учета заказов. Каждые несколько месяцев в эти приложения вносятся те или иные усовершенствования, и любое из них может служить великолепным примером безбумажного процесса, экономящего время и упрощающего контроль за предоставлением высококачественных услуг.
Мы стараемся избегать длительных циклов разработки приложений, предназначенных для внутреннего использования. Слишком продолжительные сроки часто сводят к нулю преимущества, поскольку потребности бизнеса постоянно меняются. Компактные децентрализованные процессы обычно решают задачи лучше всего. Лишь очень немногие приложения, такие, как система составления финансовых отчетов, действительно требуют централизации. Работая над решением других внутренних задач, мы всегда старались обходиться небольшими проектами с минимальным числом участников, держа в уме лозунг наших групп разработки коммерческого ПО: «Дата поставки — это одно из существенных свойств продукта».
Решая проблему администрирования штата временных сотрудников, мы стремились избежать такого «монолитного» подхода, но в то же время и не остаться в конце концов с полудюжиной разрозненных приложений, не желающих стыковаться друг с другом в целостную систему. В результате была избрана стратегия создания набора прикладных модулей, в которые с самого начала разработки закладывалось требование совместимости по используемым ими электронным данным.
Список ключевых приложений включает в себя программу корпоративных закупок MS Market, работающую в нашей интрасети; частный узел Интернета, или узел «экстрасети», MS Invoice, через который присылают нам счета агентства, поставляющие временных работников, и другие партнеры; а также ПО фирмы SAP, обслуживающее все наши финансовые транзакции. Поскольку программа HeadTrax, предназначенная как раз для автоматизации кадровой работы, находилась к тому времени уже в промышленной эксплуатации, мы использовали ее интерфейс, к которому «с обратной стороны» подключались различные другие модули. Пользователю достаточно активизировать определенную функцию из HeadTrax, a нужное внешнее приложение запускается автоматически.
