Три правила

ERP

Как стать первым на ИТ-рынке

Что нужно, чтобы стать лидером рынка? Максимальным образом удовлетворить запросы клиента с помощью продукта, качество которого (понимаемое как способность соответствовать требованиям и ожиданиям клиентов) определяется двумя составляющими:

- качеством собственно продукта, т. е. заложенными в него свойствами, удовлетворяющими определенные потребности;

- качеством предоставления продукта клиенту (предоставления в самом широком смысле слова: сюда можно отнести учет требований заказчиков при создании продукта, его рекламу, продажу и доставку клиенту, обучение специалистов заказчика, послепродажное обслуживание и т. д.).

Что касается достоинств самого продукта, то они все более нивелируются в силу следующих причин:

- глобализации капитала и активов. В итоге возможности всех игроков в смысле использования бюджетов и производственных мощностей выравниваются;

- глобализации информации. Любые новые управленческие концепции и подходы быстро становятся всеобщим достоянием;

- глобализации “мозгов”. Нивелируется человеческая индивидуальность и идет выравнивание интеллектуального уровня специалистов.

В результате и продукты все более усредняются. Если и можно говорить о каком-то превосходстве того или иного приложения, то как о временном факторе. Поэтому далее качество продукта будет зависеть в основном от качества его предоставления.

Является ли ИТ-рынок в этом смысле исключением? Нет. Более того, приоритет качества предоставления перед качеством собственно продукта здесь еще очевиднее. Во-первых, программный продукт имеет нематериальную сущность: его потребительскую ценность нельзя увидеть “живьем”, и многое зависит от того, как эти скрытые полезные его свойства доводятся до клиента. Во-вторых, программные продукты - интеллектуально сложные изделия. Чтобы клиент мог реализовать заложенные в них возможности, продукты должны быть необходимым образом предоставлены (произведена настройка под требования заказчика, организовано обучение и поддержка пользователей и т. д.).

Итак, сформулируем правило 1: чтобы стать первым, в том числе и на ИТ-рынке, необходимо позаботиться о качестве предоставления продукта клиенту.

Как это правило проецируется на “типовую” схему взаимодействия участников российского ИТ-рынка (см. рисунок)?

Существует разработчик продукта (если продукт российский) или поставщик - вендор (если продукт заграничный). Традиционно они берут на себя:

- разработку/локализацию приложения;

- централизованный маркетинг;

- продажу лицензий.

Есть еще партнеры разработчика или вендора, осуществляющие:

- продвижение продукта и своих услуг по внедрению;

- продажу указанных услуг;

- ввод прикладной системы в эксплуатацию и ее последующую поддержку и актуализацию.

И наконец, на рынке присутствуют клиенты, которые “в меру своих способностей” внедряют и эксплуатируют продукт. (Конечно, это типовая схема, в реальной жизни цепочка может быть короче или длиннее.)

В рамках данной схемы можно говорить о едином сквозном процессе предоставления продукта, связывающем всех участников и состоящем из трех групп локальных процессов:

- процессов разработчика/вендора;

- процессов партнера;

- процессов клиента.

И здесь хотелось бы высказать два замечания.

Во-первых, следует обратить особое внимание на группу процессов клиента. Дело в том, что предоставление продукта заказчику не заканчивается в момент его физической поставки на предприятие. И внедрение, и даже эксплуатация - все это тоже относится к предоставлению продукта клиенту. Почему? Потому что при внедрении команда консультантов передает прикладную систему ее будущим “эксплуататорам”. А сотрудники, которые заняты эксплуатацией внедренного продукта, в свою очередь предоставляют его топ-менеджерам (например, в виде плановых и отчетных документов). Причем в рассмотренной цепочке группа процессов клиента - это, пожалуй, самое слабое звено. А поскольку где тонко, там и рвется, сквозной процесс здесь, как правило, прерывается, и об удовлетворенности клиента можно забыть.

Во-вторых, необходимо выяснить, кто, собственно, должен отвечать за качество сквозного процесса. Можно, конечно, сказать, что у каждого из участников данной схемы свое бремя ответственности. Но так ли это?

Особенность потребительской психологии такова, что свою удовлетворенность (или неудовлетворенность) клиент в большинстве случаев связывает не с непосредственным соседом в канале предоставления продукта (продавцом), а с тем, кто стоит в начале этой цепочки - производителем, владельцем торговой марки. (В самом деле, если я приобретаю шоколад не первой свежести, то, пусть и на подсознательном уровне, некоторая часть моих отрицательных эмоций будет адресована компании, его выпускающей.) Таким образом, единственно правильным ответом на сформулированный выше вопрос будет следующий: ответственность за качество сквозного процесса предоставления продукта должен принять на себя производитель.

Подытоживая сказанное, сформулируем правило 2: разработчик/вендор должен принять на себя ответственность за действия всех участников сквозного процесса предоставления программного продукта, особое внимание уделяя финишным его этапам.

Типовая схема взаимодействия участников ИТ-рынка

В какой же степени поставщики следуют данному правилу сегодня?

Вот наблюдение, сделанное на “съезде победителей”, который проводил один из маститых разработчиков программных продуктов мирового уровня. Сотрудники вендора, представляющего разработчика на российском рынке, практически единодушно высказывались в том духе, что “мы, конечно, можем оказать помощь клиенту, но стараемся непосредственное общение с заказчиками передать партнерам, поскольку у нас с ними оговорено разделение функций и задач”. Звучит почти как “у них своя свадьба, у нас - своя”. И получается, что разработчик/вендор за деятельность партнеров отвечает, а до клиента уже не дотягивается. Но ведь удовлетворенность потребителя определяется конечным результатом!

Ну хорошо, производитель проникся нашими идеями и готов взять всю ответственность на себя. Но как ему эту ответственность реализовать?

Собственно, ответ на этот вопрос уже есть - нужна система управления качеством. Материальным воплощением этой системы является совокупность внутренних документов, формализующих и регламентирующих нормы и правила деятельности. На вопрос, как эти документы должны создаваться и использоваться, ответ тоже вроде бы очевиден: соответствующие требования сформулированы в стандартах серии ISO-9000. В адрес данных стандартов высказывается немало критических замечаний. В частности, в вину им ставится излишняя формальность. Ею отличаются как сами стандарты, так и процедуры сертификации на соответствие этим стандартам. (Формальное наличие некоторого количества документов, формальное соответствие этих документов определенным требованиям, формальное знание и соблюдение этих документов исполнителями.) Но, согласитесь, формальность или неформальность процедуры сертификации зависит только от того, как к ней отнесется само сертифицируемое предприятие.

А что касается формальности стандартов, то здесь тоже есть о чем задуматься. Что означает само понятие “стандарт”? Стандарт - это соглашение, которое обычно является результатом компромисса. А компромисс - это всегда ущемление в большей или меньшей степени наших интересов, запросов, желаний. Поэтому, соглашаясь с требованиями стандартов ISO-9000, мы всего лишь идем на определенный компромисс. А насколько при этом мы готовы ущемить свои интересы - определяем мы сами.

В этом смысле можно провести прямую аналогию между стандартами серии ISO-9000 и “Книгой о вкусной и здоровой пище”. С одной стороны, наличие этой книги не обязывает нас готовить все упомянутые там блюда. С другой стороны, эта книга может и не содержать все необходимые нам рецепты. Так же надо относиться и к стандартам ISO-9000: для конкретного предприятия они могут оказаться в чем-то недостаточными, а в чем-то и избыточными. Именно поэтому для обозначения создаваемой на предприятии совокупности нормативных документов мы предлагаем более нейтральный термин - система внутреннего нормативного регулирования (СВНР). И уже вопрос второй, насколько СВНР конкретного предприятия будет коррелировать с требованиями стандартов ISO-9000: окажется ли это соответствие полным или из ISO-9000 будет взята одна только идеология.

Если теперь вернуться к рассматриваемой схеме сквозного процесса, то можно сформулировать правило 3: качество работы сквозного канала должна обеспечить система внутреннего нормативного регулирования, охватывающая всех его участников и включающая:

- СВНР разработчика/вендора;

- СВНР партнера;

- СВНР клиента.

Что касается СВНР разработчика/вендора, то здесь, видимо, особые комментарии не требуются. Он просто создает совокупность внутренних регламентирующих документов.

СВНР партнеров. В какой степени разработчик/вендор будет регулировать (через нормативные документы) деятельность партнеров? Возможны самые разные варианты:

- по степени охвата деятельности партнеров нормативными документами (например, регламентируются процедуры внедрения, а процессы проведения маркетинга игнорируются);

- по степени детализации (например, партнерам задаются некие рамочные условия, а все детали они прописывают сами);

- по степени обязательности выполнения (от жестко регламентирующих документов до методических рекомендаций).

Разработчик/вендор при этом будет принимать во внимание количество партнеров, их опыт и квалификацию, а также принципы своей партнерской политики.

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

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

Если же вернуться к роли разработчика/вендора в строительстве СВНР клиентов, то представляется, что от него должны исходить если и не заготовки документов, то хотя бы четкий их перечень и недвусмысленные требования к их содержанию.

Какова же ситуация с регламентацией деятельности у российских участников ИТ-рынка на сегодняшний день? Явно не блестящая. Приведем один лишь пример из нашей практики. Клиент, внедривший у себя учетный модуль одной очень тяжелой системы, спустя некоторое время обратился к нам за помощью в написании группы учетных стандартов. Почему? Да потому, что перестал понимать получаемую на выходе информацию: возникли трудности с ее анализом, оценкой и интерпретацией. Хорошо, что прозрение все же наступило. Но ведь логичнее было бы поступить наоборот - сначала стандарты, потом внедрение. И внедрили бы быстрее, и управленческая ценность получаемой информации была бы выше.

Конечно, строительство СВНР - хлопотное занятие. Но альтернативы у разработчиков, если они действительно хотят реализовать свои “имперские” амбиции, по сути и нет. Каковы сегодняшние тенденции?

С одной стороны, все более возрастает сложность программных продуктов (в первую очередь - функциональная). Это приводит к увеличению цены лицензии и стоимости внедрения. Кроме того, сложное приложение требует наличия квалифицированных кадров как у партнеров, так и у клиентов.

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

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

В целом же СВНР сквозного процесса обеспечивает соблюдение интересов всех его участников:

- заказчик осознанно, “с чувством глубокого удовлетворения” внедряет и эксплуатирует программный продукт, который обеспечивает ему реальную управленческую прибавочную стоимость;

- партнер реализует проект без нервных потрясений, всегда соблюдая бюджет и сроки;

- разработчик, имея счастливых клиентов и партнеров, может спокойно вербовать новых. А что еще нужно, чтобы стать первым? *1

_____

*1. Возможно, еще нужна страна, в которой ИТ-индустрия построена не на деморализующей отрасль откатной экономике. - Прим. ред.

С автором можно связаться по e-mail: schebek@yandex.ru.