При обсуждении взаимодействия ИТ-службы (будь то внутреннее ИТ-подразделение в организации или сторонняя ИТ-организация) с контрагентами, довольно часто происходит блуждание в, казалось бы, трёх соснах. Как обозначить одну сторону этих взаимоотношений, обычно вопросов не возникает – «ИТ» или «поставщик ИТ-услуг» (вслед за ITIL’овским «IT service provider»). А вот для обозначения второй могут использоваться разные слова: «заказчик», «бизнес», «потребитель», «клиент», «пользователь» (реже «покупатель» и т.д.). Причём, когда в обсуждении участвуют несколько коллег, да ещё с опытом работы в разных компаниях, ситуация напоминает знаменитое столпотворение.
С «пользователями» разбираемся довольно быстро – это те, кто пользуется ИТ-услугами; user-ы в привычном для ИТ-специалистов смысле слова. А с «заказчиками» приходиться повозиться.
Не претендуя на то, чтобы заменить данной заметкой содержимое толковых словарей или оспорить терминологию нормативных актов (НК, ГК РФ и т.п.), желая в том числе избежать занимательного флейма, подобного этому, попробую предложить вариант систематизации и обратить внимание на особенности использования данного термина в ITIL.
Наверное, самое простое наполнение смыслом слова «заказчик» (customer) – это тот, кто заказывает. Как часто говорят: «Тот, кто платит». Если речь идёт о взаимодействии с внешним ИТ-поставщиком, то это довольно понятная картина. Если речь идёт о внутреннем ИТ-подразделении, то заказчики – это те, кто так или иначе влияют на формирование задач для ИТ. Обычно это различные подразделения компании, сотрудники которых используют информационные технологии как инструмент в своей работе.
Причём называть их «бизнесом» тоже не совсем точно, поскольку постановкой задач для ИТ занимается, например, в том числе бухгалтерия, которая сама является сервисным подразделением, и непосредственно к бизнесу компании, т.е. к формированию ценности для внешних клиентов компании (если это не бухгалтерский бизнес) отношения не имеет. Бухгалтерия, как и ИТ, во многих случаях – поддерживающая функция.
Руководство таких подразделений, будучи (если) заинтересованным в повышении эффективности своих подразделений формирует свои потребности (при помощи поставщика услуг, конечно же) и оплачивает их, так или иначе влияя на формирование бюджета ИТ или производя прямые расчёты с ИТ, что тоже встречается.
При этом нужно помнить, что сценарии могут быть сложными, и, кроме того, иногда мы имеет дело не с цепочкой создания ценности, а с сетью создания ценности. В заметке «Value network и сервисный подход» подробно описано, что «заказчиков» может быть больше одного (в зависимости от того, как мы подходим к формированию каталога услуг). И возможна ситуация, когда «тот, кто платит» и «заказчик» – разные подразделения.
В некоторых компаниях схема усложняется за счёт того, что заказчиком (customer) выступает генеральный подрядчик, который оказывает услуги своему заказчику. Которого, чтобы не запутаться, в первой компании называют «конечным заказчиком» (end customer).
Если посмотрим текст ITIL, то увидим очень похожую картину.
Customer [ITIL®, Service Strategy, Glossary]
Someone who buys goods or services. The customer of an IT service provider is the person or group who defines and agrees the service level targets. The term is also sometimes used informally to mean user – for example, ‘This is a customer-focused organization.’
“Заказчик – тот, кто покупает товары или услуги. Заказчик для поставщика ИТ-услуг – это человек или группа людей, которые определяют и согласуют целевые показатели SLA. Термин также иногда неформально используется для обозначения пользователей (user)”
Идентичное определение приведено в разделе 1.2.2 «ITIL Practitioner Guidance».
Ещё один момент, на который стоит обратить внимание – использование термина «заказчик» (customer) при описании процессов в ITIL.
Например, в разделе 2.2.2 ITIL, Service Strategy сказано, что ключевые характеристики процесса должны включать описание заказчика (customers): “Every process delivers its primary results to a customer or stakeholder. Customers may be internal or external to the organization, but the process must meet their expectations.” (“Каждый процесс предоставляет свои основные результаты заказчику или заинтересованной стороне”)
Этот же момент более подробно развёрнут в «ITIL Practitioner Guidance». В разделе 2.1.2 «The customer for processes» помимо ссылки на упомянутый параграф 2.2.2. в 2 ITIL, Service Strategy, приводится пример с улучшением процесса управления изменениями за счёт увеличения доли стандартных изменений, касающихся инфраструктуры, в результате которого основную выгоду получают сотрудники инфраструктурной команды:
If the change management process is improved through the conversion of a significant number of normal infrastructure changes into standard changes (usually allowing for a significant proportion of these to be automated), the team members who manage the infrastructure will experience direct value in the form of the ability to work more rapidly and more simply.
Но косвенно улучшение процесс управления изменениями, описанное в данном примере, приведёт и к улучшению услуг. От чего выиграют… конечные заказчика («end customers») [там же]:
But these process improvements will also indirectly benefit the end customers in that they can make use of service improvements that depend on infrastructure changes more rapidly and with less disruption.
Т.е. инфраструктурная команда – заказчики (явно в тексте это не обозначено, но следует логически), а потребители услуг – конечные заказчики (явно обозначено в тексте)? 🙂
На самом деле концепция внутренних и внешних заказников старше ITIL. Как и спор о том, что первично. С одной стороны, деятельность любой компании направлена на ценность для внешнего заказчика – клиента данной компании. С другой, если рассмотреть деятельность такой компании в виде (для простоты) цепочки/потока создания ценности (например, ИТ представляет ИТ-услугу бизнес-подразделению, которое предоставляет услугу внешнему клиенту), то можно рассуждать по-разному.
- Все усилия всех подразделений/функций направлены на удовлетворение потребности внешнего клиента. Того, за чей счёт компания зарабатывает. (И такие лозунги иногда звучат)
- Каждое подразделение/функция работает на своего непосредственного заказчика. В данном примере ИТ на бизнес-подразделение, а бизнес-подразделение – на внешнего клиента. Вытягивающий принцип производства (привет, Lean!) и вот это всё.
Если организационная структура и схема взаимодействия сложные (особенно, если сложность понимать так, как это описано в квадранте «Complex» модели Cynefin), то только выстраивание работающего потока с принципом вытягивания и будет работать. Это подтверждено практикой и в таких, казалось бы, детерминированных процессах как дискретное производство (например, автомобилестроение), и в таких творческих, какие встречаются в ИТ.
Конечно, видится разумным при этом создание такой среды, в которой все сотрудники компании понимают, как устроен поток создания ценности, в чём она, эта ценность, состоит. Как сказал наш великий полководец: “Каждый солдат знай свой маневр!” Миссия, стратегия, визуализация потока… Опять же, Lean, DevOps и т.п.
В общем, с термином «заказчик» всё действительно не так просто. И, очевидно, при возникновении дискуссии нужно первым делом уточнить терминологию и контекст (в зависимости от которого один и тот же термин может означать разные вещи).
