ИСПОЛЬЗОВАНИЕ ЭЛЕКТРОННЫХ ПРОЦЕССОВ ДЛЯ РЕШЕНИЯ СЛОЖНЫХ ПРОБЛЕМ
Одним из самых сложных в Microsoft оказался процесс найма, администрирования и оплаты труда временных работников.
Для компании с большим числом проектов, работа над которыми оживляется ближе к дате выпуска готового продукта, грамотное управление наймом временной рабочей силы жизненно необходимо. Мы пользуемся услугами таких работников, чтобы справляться с пиковыми нагрузками на всех участках, от разработки и тестирования до маркетинга и административной поддержки. Применение их труда в Microsoft требует координации между пятью группами лиц, к каковым относятся: 1) сами временные работники; 2) ПО поставляющих их нам агентств; 3) менеджеры различных подразделений, которым требуется дополнительная рабочая сила; 4) наша внутренняя группа найма временных работников, занимающаяся назначением почасовых ставок для них и отношениями с агентствами; 5) отдел снабжения, который, собственно, и оплачивает счета.
Проблема заключала в себе множество аспектов. Дело было не только в огромном объеме бумажной работы по заключению контрактов с множеством различных агентств и работников. Мы испытывали сложности еще и с обеспечением единого процесса заключения контрактов; подбором подходящих специалистов и назначением им адекватных почасовых ставок; предотвращением ситуаций, когда одному человеку приходится часто переключаться с одного проекта на другой или, напротив, слишком долго заниматься одним и тем же проектом; а также с принятием решений о приглашении временных сотрудников в штат.
Кадровая политика, разработанная несколько лет назад, предусматривала ряд строгих правил использования временной рабочей силы. В соответствии с ней таких работников можно было нанимать только через агентства, и ни один из них не мог участвовать в наших проектах — независимо от их общего количества и комбинации — более 340 дней подряд без перерыва продолжительностью хотя бы в 31 день. Однако при использовании бумажного процесса контроль за соблюдением этой политики менеджерами, привлекающими временных работников — а многие из них сами были новичками в компании или лишь недавно начали отправлять данную обязанность, — представлял значительную трудность. Учитывая склонность руководителей проектов развертывать деятельность по поиску нужных работников только тогда, когда обходиться без их услуг становится совсем уже невмоготу, единственной возможностью удовлетворить потребности подразделений в рабочей силе и избежать грубых ошибок было подключение большого числа специалистов по кадровой работе. Такой «человекоемкий» процесс никого не мог устроить.
Более того, бумажный процесс не позволял высшему руководству адекватно решать бюджетную проблему. Поскольку, с одной стороны, временную рабочую силу использовали многие отделы, а с другой, временные работники нередко участвовали каждый в нескольких проектах сразу, главе подразделения оказывалось трудно подсчитать общее число таких сотрудников или отработанных ими часов. Было невозможно дать сколько-нибудь надежный прогноз расходов на оплату их труда. Отчетные данные по числу работников и их выработке в часах и в денежном выражении, которые старшие менеджеры получали от финансовых отделов, всегда запаздывали; а более оперативно можно было получить лишь приблизительные оценки. Размеры выплат испытывали резкие колебания от месяца к месяцу.
Сначала мы думали, что проблема коренится в организации работы финансовых отделов, но, проанализировав имеющуюся информацию, поняли, что они просто плохо обеспечены исходными данными. Наш процесс оплаты труда имел слишком мало управляемых параметров. Несмотря на большое число виз — менеджеры подписывали карточки учета отработанных временными работниками часов, те представляли их в свои агентства, агентства же выставляли счета отделу снабжения, который их оплачивал, — какие-либо финансовые рычаги управления фактически полностью отсутствовали. По полученному от агентства счету менеджер не мог проверить ни почасовую ставку, ни количество отработанных часов. Более того, счет мог быть выставлен даже в отсутствие подписанной карточки учета часов. Или нанимающий менеджер соглашался на повышение почасовой ставки, а до специалистов, занимающихся оформлением временных работников, эта информация вовремя не доходила. Или ставка повышалась по одному из проектов, а оплата по ошибке увеличивалась и по всем остальным. Не существовало и никакого способа предотвратить повторное выставление счетов за одну и ту же работу.
«Поднявшись над процессом», мы изучили его от начала и до конца и рассмотрели возможности его упрощения с помощью электронного информационного инструментария.
Одна из проблем с администрированием заключалась в том, чтобы решить, следует ли предоставлять менеджерам, нуждающимся во временных работниках, полномочия самостоятельно их нанимать. При использовании старого бумажного процесса не было никакого способа пересмотреть однажды принятое решение о привлечении дополнительных ресурсов. Подписав представление о найме временного работника, менеджер даже не мог проверить, соответствуют его дальнейшие действия установленным правилам или нет. Например, достаточно ли в бюджете средств для оплаты этой дополнительной работы? Следует ли разрешить оплату сверхурочных по данному проекту? Кроме того, руководителю, нуждающемуся во временной рабочей силе, было очень непросто составить себе представление о том, какая почасовая ставка будет адекватна предполагаемым обязанностям нового сотрудника и как подойти к подбору квалифицированного исполнителя для них. Не имея на примете конкретного работника, было нелегко решить даже вопрос о том, где его искать — обратиться в какую-либо компанию, в агентство или же найти независимого специалиста? Нам необходим был некий способ, позволяющий заранее автоматически рассчитывать полную сумму расходов, чтобы закладывать ее в бюджет.
Было решено, что для этого требуется гибкое программное решение. Оно должно было гарантировать составление и подписание контракта с каждым временным работником еще до того, как он приступит к исполнению своих обязанностей. По заключении контракта для него в течение 48 часов должны были подготавливаться пластиковая карточка для прохода через турникеты системы безопасности, внутренний телефонный номер и учетная запись доступа в корпоративную сеть. Система должна была позволять легко создавать сразу несколько идентичных запросов на однотипные вакансии, что весьма типично для крупных проектов. В процессе исполнения контракта менеджер должен был иметь возможность легко проверить число отработанных часов, ставку и остаток денег, выделенных на оплату по нему в течение всего проекта или этапа. С приближением даты окончания контракта соответствующему нанимающему менеджеру должно было автоматически выдаваться соответствующее уведомление и предоставляться возможность продлить данный контракт, но только при условии, что в бюджете остается достаточно средств и что время, уже отработанное данным работником на Microsoft без перерывов, не превышает 340 дней. С окончанием срока контракта доступ к корпоративной компьютерной сети и в здания компании должен был автоматически закрываться, а адрес электронной почты и телефонный номер — освобождаться.
Кроме того, новый процесс ни при каких обстоятельствах не должен был создавать задержек в работе. Если руководитель, в чью компетенцию входит утверждение контрактов, оказывался в нужный момент недоступен, нанимающий менеджер должен был иметь возможность получить подпись от другого человека, обладающего необходимыми полномочиями. В случае перевода контракта в ведение другого менеджера или другого учетно-калькуляционного подразделения не должно было возникать сложностей с перераспределением издержек. Агентствам предоставлялось право самостоятельно повышать ставку временного работника в небольших пределах, но крупное повышение требовало визы нанимающего менеджера.

НУЖНА ЛИ ЦЕНТРАЛИЗАЦИЯ
Один из возможных подходов к автоматизации процессов состоит в создании громадного монолитного приложения, решающего все поставленные задачи, — это подход «одной большой программы». Однажды мы испробовали его на практике — когда попытались написать единое приложение приема и выполнения заказов для целой дюжины своих вспомогательных подразделений: библиотеки, службы безопасности, столовой, отдела бронирования билетов и гостиниц, магазина, отдела корпоративных кредитных карточек и др. В конечном итоге этот проект оказался в числе немногих, которые пришлось свернуть. Потребности различных служб были слишком разнообразными, и бизнес-правила получались слишком сложными для обработки одним приложением. На доведение системы до рабочего состояния ушло столько времени, что, когда она была готова, требования пользователей успели уже измениться. Из этой истории мы вынесли один важный урок: лишь очень немногие приложения, предназначенные для корпоративного применения, требуют «центральной» точки зрения. После такой неудачной попытки каждой группе была предоставлена возможность самостоятельно построить собственную систему обработки заказов. Уменьшение масштаба значительно упростило задачу и сократило время разработки. Сегодня все вспомогательные подразделения пользуются собственными программами учета заказов. Каждые несколько месяцев в эти приложения вносятся те или иные усовершенствования, и любое из них может служить великолепным примером безбумажного процесса, экономящего время и упрощающего контроль за предоставлением высококачественных услуг.
Мы стараемся избегать длительных циклов разработки приложений, предназначенных для внутреннего использования. Слишком продолжительные сроки часто сводят к нулю преимущества, поскольку потребности бизнеса постоянно меняются. Компактные децентрализованные процессы обычно решают задачи лучше всего. Лишь очень немногие приложения, такие, как система составления финансовых отчетов, действительно требуют централизации. Работая над решением других внутренних задач, мы всегда старались обходиться небольшими проектами с минимальным числом участников, держа в уме лозунг наших групп разработки коммерческого ПО: «Дата поставки — это одно из существенных свойств продукта».
Решая проблему администрирования штата временных сотрудников, мы стремились избежать такого «монолитного» подхода, но в то же время и не остаться в конце концов с полудюжиной разрозненных приложений, не желающих стыковаться друг с другом в целостную систему. В результате была избрана стратегия создания набора прикладных модулей, в которые с самого начала разработки закладывалось требование совместимости по используемым ими электронным данным.
Список ключевых приложений включает в себя программу корпоративных закупок MS Market, работающую в нашей интрасети; частный узел Интернета, или узел «экстрасети», MS Invoice, через который присылают нам счета агентства, поставляющие временных работников, и другие партнеры; а также ПО фирмы SAP, обслуживающее все наши финансовые транзакции. Поскольку программа HeadTrax, предназначенная как раз для автоматизации кадровой работы, находилась к тому времени уже в промышленной эксплуатации, мы использовали ее интерфейс, к которому «с обратной стороны» подключались различные другие модули. Пользователю достаточно активизировать определенную функцию из HeadTrax, a нужное внешнее приложение запускается автоматически.
Процесс заключения трудового договора начинается с электронного оформления требования на закупку (в данном случае рабочей силы) в приложении MS Market, которое подробно описано в главе 3. Операции создания регистрационных записей временных работников, их найма и администрирования очень похожи на те, что предусмотрены в HeadTrax для штатных сотрудников. Программа MS Invoice обеспечивает прием счетов в электронной форме и позволяет как нанимающему менеджеру, так и агентству по найму контролировать исполнение бюджета. По получении каждого счета нанимающий менеджер может проверить, сколько еще денег остается (и остается ли) на счету соответствующего заказа. А агентства по найму сверяют с помощью системы полученные суммы с выставленными счетами. Если попытаться выставить счет на сумму, превышающую остаток по соответствующему заказу, он не будет принят. Если же агентство решит повысить ставку своего работника, менеджеру Microsoft достаточно одного нажатия на кнопку мыши, чтобы утвердить или отвергнуть это изменение в контракте.
У вдумчивого читателя может возникнуть вопрос, а зачем нам вообще нужны все эти счета, электронные или нет? В конце концов, ведь удалось же лидерам ряда производственных отраслей исключить их из своего документооборота. Классическим примером может служить корпорация Ford, обходящаяся без счетов при закупке комплектующих. Когда партия запасных частей поступает на склад, приемщик просто вводит в электронную систему сообщение об этом, и механизм перечисления платежа поставщику запускается автоматически. Производитель получил комплектующие, а поставщик — деньги. Кому нужны счета — хотя бы даже и электронные?
Мы поэкспериментировали с этим подходом, однако натолкнулись на ряд сложностей, обусловленных отличиями услуг от товаров. В производстве каждый компонент имеет свой инвентарный номер. А при получении «рабочих часов» временного участника проекта организовать их учет аналогичным образом оказывается не так просто. Агентству, из которого он пришел, необходимо ассоциировать каждый полученный платеж со своим конкретным работником и конкретной рабочей неделей, что очень непросто сделать, не пользуясь такой справкой, как выставленный и оплаченный счет. Создание системы платежей без выставления счетов, которая устраивала бы наших поставщиков, остается пока делом будущего.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70