Цели и задачи описания бизнес-процессов

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

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

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

Например, если целью является последующая автоматизация, то целесообразно строить модели в нотациях и средствах моделирования, рекомендуемых для тех систем, которые планируется внедрять: eEPC и ARIS для SAP ERP, BPMN и BizAgi ProcessModeler для BPM-системы BizAgi и т.п. У многих крупных разработчиков IT-решений в линейке продуктов есть и соответствующие средства для моделирования бизнес-процессов, в свою очередь многие независимые разработчики средств моделирования обеспечивают средства конвертации моделей в форматы для использования внешними информационными системами. Учет этих моментов на раннем этапе позволит на выходе достичь лучшего понимания описанных процессов участниками будущего проекта автоматизации и сэкономить время на перерисовке одних и тех же процессов в разных нотациях и/или средствах моделирования.

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

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

Бизнес-процессы описаны и что дальше?

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

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

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

Итак, начнем с начала: бизнес-процессы описаны, работа завершена J! А теперь подумаем, что можно с ними сделать дальше.

Первое. Доведем информацию о бизнес-процессах до всех их участников!

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

Второе. Дадим возможность высказаться!

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

Третье. Воспользуемся современными решениями для оптимизации бизнес-процессов!

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

Четвертое. Подумаем о внедрении BPM-системы!

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

Пятое. Не забудем о SMART!

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

Шестое. Система важнее всего!

Можно, конечно, принять это как субъективное мнение человека, обладающего системным вариантом мышления J. Однако, очевидно то, что развитие бизнес-процессов должно строиться по тем же законам, что и общее организационное развитие, поскольку является его неотъемлемой частью. А в современном менеджменте уже давно господствует системный подход, в который, тем не менее, отлично вписываются различные «иррациональные компоненты»: личная инициатива, лидерство и тому подобные понятия. Возвращаясь к описаниям бизнес-процессов, это означает то, что для развития процессов в конкретной организации необходимо разработать и формализовать новый «мета-процесс», назначить ответственных лиц, при необходимости написать должностные инструкции и «регламент совершенствования бизнес-процессов». Скелетом этого мета-процесса, как ни крути, будет являться классический цикл Деминга, который необходимо развить и приложить к особенностям предметной области, отрасли и конкретной организации. Помочь в этом могут многочисленные методологии и программные средства (например, методология «Business Process Excellence» и соответствующее ПО ARIS). Хотя, по моему скромному мнению, отличных результатов можно добиться и «подручными средствами», вполне доступными даже совсем небольшим компаниям.

Седьмое. Подумайте о привлечении консультанта!

Здесь без комментариев J. Пишите — обсудим любые удобные для Вас варианты сотрудничества!

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

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

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

Рассмотрим простой пример. Наемный сотрудник в компании заработал 100.000$ и размышляет над тем, как максимально эффективно вложить эти деньги. Ему доступны два инструмента инвестирования: банковский депозит (фиксированная доходность 10% в год) и покупка акций (доходность зависит от ситуации на рынке). Для простоты примем, что вариантов действия в данном случае всего три: 100% средств положить на депозит, 100% вложить в акции и поделить средства пополам между акциями и депозитом. Требуется принять оптимальное решение, обеспечивающее максимальную доходность.

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

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

В данном случае могут быть использованы следующие критерии сравнения вариантов.

Оценка вероятностей сценариев

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

Если вероятности позитивного, нейтрального и негативного сценариев равны соответственно 40%, 50% и 10%, то ожидаемая доходность будет иметь следующие значения.

Поэтому, следует на 100% инвестировать в акции.

Критерий Лапласа

Если нет оснований считать, что какой либо из вариантов более вероятен по сравнению с другими, то все сценарии принимаются равновероятными.

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

Критерий Вальда

Очень осторожная стратегия. По каждому варианту действий выбирается результат для наихудшего сценария. Затем выбирается вариант действий с максимальным из наихудших результатов.

В данном случае с точке зрения гарантированного сохранения средств также лучше 100% депозит.

Критерий Гурвица

Ориентация на наихудший результат часто является перестраховкой. Вместе с тем опрометчиво выбирать чрезмерно оптимистичную политику. Критерий Гурвица рассматривает для каждого варианта действий наихудший и наилучший сценарий. Вводит понятие «коэффициента оптимизма» (a) — вероятности наилучшего сценария. Вероятность наихудшего сценария равна (1-a). Промежуточные сценарии не рассматриваются. Далее для некоторого набора (a) считаются математические ожидания прибыли.

Отсюда видим, что в зависимости от степени нашего оптимизма мы можем выбрать либо 100% депозит, либо 100% акции.

Критерий Сэвиджа

В данном случае анализируется упущенные возможности, т.е. убытки от неправильного решения. Например, было принято решение инвестировать на 100% депозит, а сценарий будущего оказался оптимистичным, то упущенная выгода для этого варианта действий при реализации данного сценария равна 10.000$ (полученный доход) – 20.000$ (можно было бы получить, если бы было принято решение купить 100% акции) = -10.000$ (получено на 10.000$, чем можно было бы получить).

Рассчитаем упущенную выгоду для всех сценариев и всех вариантов действий.

Далее для каждого варианта действий определяем наихудшее значение упущенной выгоды. Решением является вариант действий с наилучшим из наихудших значений. В нашем случае эквивалентны варианты 100% депозит и пополам акции и депозит.

Экспертные методы принятия решений

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

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

Метод совещаний

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

Достоинством данного метода является простота его реализации. Недостатком – зависимость от красноречия ораторов, за которым может скрываться недостаточная компетентность в рассматриваемых вопросах.

Метод суда

Мeтoд «cyдa» являeтcя paзнoвиднocтью мeтoдa «coвeщaний» и peaлизyeтcя пo aнaлoгии c вeдeниeм cyдeбнoгo пpoцecca. В poли «пoдcyдимыx» выcтyпaют выбиpaeмыe вapиaнты peшeния; в poли «cyдeй» — лицa, пpинимaющиe peшeниe; в poли «пpoкypopoв» и «зaщитникoв» — члeны экcпepтнoй гpyппы. Рoль «cвидeтeлeй» выпoлняют paзличныe ycлoвия выбopa и дoвoды экcпepтoв. Пpи вeдeнии тaкoгo «cyдeбнoгo пpoцecca» oтклoняютcя или пpинимaютcя тe или иныe peшeния.

Мeтoд «cyдa» цeлecooбpaзнo иcпoльзoвaть пpи нaличии нecкoлькиx гpyпп экcпepтoв, пpидepживaющиxcя paзличныx вapиaнтoв peшeния.

Мозговой штурм

Мeтoды этoгo типa извecтны тaкжe пoд нaзвaниeм кoллeктивнoй гeнepaции идeй, мoзгoвoгo штypмa, диcкyccиoнныx мeтoдoв. Вce эти мeтoды ocнoвaны нa cвoбoднoм выдвижeнии идeй, нaпpaвлeнныx нa peшeниe пpoблeмы. Зaтeм из этиx идeй oтбиpaютcя нaибoлee цeнныe.

Дocтoинcтвoм мeтoдa «мoзгoвoй aтaки» являeтcя выcoкaя oпepaтивнocть пoлyчeния тpeбyeмoгo peшeния. Оcнoвным нeдocтaткoм eгo — cлoжнocть opгaнизaции экcпepтизы, тaк кaк инoгдa нeвoзмoжнo coбpaть вмecтe тpeбyeмыx cпeциaлиcтoв, coздaть нeпpинyждeннyю aтмocфepy и иcключить влияниe дoлжнocтныx взaимooтнoшeний.

Метод сценариев

Мeтoд «cцeнapиeв» пpeдcтaвляeт coбoй coвoкyпнocть пpaвил пo излoжeнию в пиcьмeннoм видe пpeдлoжeний cпeциaлиcтoв пo peшaeмoй пpoблeмe. Сцeнapий пpeдcтaвляeт coбoй дoкyмeнт, coдepжaщий aнaлиз пpoблeмы и пpeдлoжeния пo ee peaлизaции. Пpeдлoжeния внaчaлe пишyт экcпepты индивидyaльнo, a зaтeм oни coглacyютcя и излaгaютcя в фopмe eдинoгo дoкyмeнтa.

Оcнoвным пpeимyщecтвoм cцeнapия являeтcя кoмплeкcный oxвaт peшaeмoй пpoблeмы в дocтyпнoй для вocпpиятия фopмe. К нeдocтaткaм мoжнo oтнecти вoзмoжныe нeoднoзнaчнocть, нeчeткocть излaгaeмыx вoпpocoв и нeдocтaтoчнyю oбocнoвaннocти oтдeльныx peшeния.

Метод Дельфи

Мeтoд «Дeльфи», или мeтoд «дeльфийcкoгo opaкyлa», пpeдcтaвляeт coбoй итepaтивнyю пpoцeдypy aнкeтнoгo oпpoca. Пpи этoм coблюдaeтcя тpeбoвaниe oтcyтcтвия личныx кoнтaктoв мeждy экcпepтaми и oбecпeчeния иx пoлнoй инфopмaциeй пo вceм peзyльтaтaм oцeнoк пocлe кaждoгo тypa oпpoca c coxpaнeниeм aнoнимнocти oцeнoк, apгyмeнтaции и кpитики.

Пpoцeдypa мeтoдa включaeт нecкoлькo пocлeдoвaтeльныx этaпoв oпpoca. Нa пepвoм этaпe пpoизвoдитcя индивидyaльный oпpoc экcпepтoв, oбычнo в фopмe aнкeт. Экcпepты дaют oтвeты, нe apгyмeнтиpyя иx. Зaтeм peзyльтaты oпpoca oбpaбaтывaютcя и фopмиpyeтcя кoллeктивнoe мнeниe гpyппы экcпepтoв, выявляютcя и oбoбщaютcя apгyмeнтaции в пoльзy paзличныx cyждeний. Нa втopoм — вcя инфopмaция cooбщaeтcя экcпepтaм и иx пpocят пepecмoтpeть oцeнки и oбъяcнить пpичины cвoeгo нecoглacия c кoллeктивным cyждeниeм. Нoвыe oцeнки внoвь oбpaбaтывaютcя и ocyщecтвляeтcя пepexoд к cлeдyющeмy этaпy. Пpaктикa пoкaзывaeт, чтo пocлe тpex-чeтыpex этaпoв oтвeты экcпepтoв cтaбилизиpyютcя, и нeoбxoдимo пpeкpaщaть пpoцeдypy.

Дocтoинcтвoм мeтoдa «Дeльфи» являeтcя иcпoльзoвaниe oбpaтнoй cвязи в xoдe oпpoca, чтo знaчитeльнo пoвышaeт oбъeктивнocть экcпepтныx oцeнoк. Однaкo дaнный мeтoд тpeбyeт знaчитeльнoгo вpeмeни нa peaлизaцию вceй мнoгoэтaпнoй пpoцeдypы.

Заключение

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

Линейное программирование

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

Для примера рассмотрим простую задачу, которую решим графически.

Пусть перед компанией А стоит задача организовать рекламную компанию, длительностью один месяц, на которую выделено в бюджете 10.000$. Имеется возможность разместить рекламный ролик на радио (стоимость минуты эфирно времени на радио 500$) и/или на телевидении (стоимость минуты на местном TV равна 1000$). Имеются статические данные об эффективности маркетинговых каналов. Так 1 минута на телевидении в среднем обеспечивает рекламодателю 15 новых клиентов, а 1 минута на радио – 10 новых клиентов. Кроме того, все рекламодатели должны соблюдать местное антимонопольное законодательство, в рамках которого общая длительность транслированных по всем каналам рекламных роликов не должна превышать 15 минут в месяц.

Вопрос: каким образом максимально эффективно (по количеству новых клиентов) с учетом бюджетного и законодательного ограничения распределить рекламную кампанию между радио и ТВ?

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

F(X,Y) = 10*X + 15*Y

Ограничения:

500*X + 1000*Y <= 10.000 (бюджетное)

X + Y <= 15 (законодательное)

X >= 0, Y >= 0 (очевидное)

Теперь изобразим имеющиеся ограничения графически.

Многоугольник, с вершинами 1, 2, 3 и 4 представляет из себя множество возможных значений X и Y, удовлетворяющих заданным ограничениям (заштрихованная область).

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

Рассчитаем значения F(X,Y) в точках 1-4.

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

Календарно-сетевое планирование

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

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

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

Наряду с сетевым графиком для принятия решений в области управления проектами используется линейная диаграмма (или ее разновидность, на которой также обозначены взаимосвязи между работами – диаграмма Ганта).

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

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

Теория игр

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

Рассмотрим применение элементов теории игр на примере т.н. дилеммы заключенных. Пойманы два преступника (A и B), совместно совершивших одно вооруженное ограбление. Однако, следствие не может доказать, что вооруженное ограбление совершили именно они. Следствие может лишь доказать, что они незаконно носили оружие. По закону за вооруженное ограбление положено тюремное заключение сроком на 10 лет, за ношение оружия – 1 год тюрьмы. В связи со сложившейся ситуацией следователь предлагает каждому участнику сознаться. Также он сообщает, что если сознаются оба участника, то каждому из них срок будет сокращен в два раза до 5-ти лет. Возможности общаться между собой у заключенных нет. Вопрос: следует ли каждому из заключенных сознаться или продолжать молчать?

В данном случае следователь придумал условия «игры». А заключенные A и B играют в нее между собой. Для описания условий игры между двумя игроками и возможных сценариев обычно используется матрица, измерениями которой являются возможные сценарии (выборы) каждого игрока, а в ячейках результат игры в случае данного сочетания выборов двух игроков.

Для краткости и четкости обозначим в ячейках матрицы результаты для игроков A и B в виде: результат А, результат B.

Заключенные хотят получить «гарантированный» оптимальный результат игры при любых стратегиях другого игрока. Для этого, т.к. заключенные не связаны друг с другом, при принятии решения (сознаться или молчать) они рассматривают для каждой возможной стратегии наихудший результат. Так, если заключенный A сознается, то его наихудший результат равен -10 (если B сознается). В случае же, если А будет продолжать молчать, то его наихудший результат равен -1 (если B также будет продолжать молчать). Следовательно, А выбирает для себя стратегию «молчать», как наиболее эффективную при любых действиях B. Нетрудно увидеть, что для B «молчать» — также оптимальная стратегия. В итоге оба заключенных будут молчать и выйдут на свободу через год. Если кто-то из них не владеет аналитическим аппаратом принятия решения, то он в итоге может просидеть в тюрьме 5 или даже 10 лет, за счет чего владеющий им может выйти сразу на свободу.

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

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

В этом случае матрица результатов для заключенных выглядит следующим образом.

Наихудшие результаты для А при любых действиях B, если сознаться = -5, если молчать = -10. Следовательно, А выгоднее сознаться. Аналогично выгоднее сознаться и B. Следовательно, оба подозреваемых сознаются и получат по 5 лет тюрьмы.

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

Матрица тогда выглядит так.

Наихудшие результаты для А при любых действиях B, если сознаться = -30, если молчать = -10. Следовательно, А, как и B, выгоднее молчать. В итоге оба получат всего лишь по году тюрьмы.

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

Теория очередей

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

Рассмотрим обобщенную модель очереди.

«Входной поток» представляет из себя общий поток заявок желающих получить обслуживание. «Канал обслуживания» обрабатывает не более одной заявки одновременно. Для одновременной обработки N заявок может использоваться N каналов. «Выходной поток» — обработанные заявки. Если интенсивность входного потока (число заявок в единицу времени) превышает число каналов обслуживания, то «не помещающиеся» заявки становятся в «очередь» с тем, чтобы быть обработанными в следующую единицу времени.

Наглядным примером, который может быть описан при помощи данной модели является Call-центр оператора связи. Так абоненты, желающие получить консультацию по телефону, образуют входной поток. Канал обслуживания – оператор. Call-центр — группа операторов, обрабатывающих телефонные звонки. Если в Call-центре есть свободный оператор, то абонент сразу попадает на него, минуя очередь. Если в Call-центре все операторы заняты, то он становится в очередь и слушает музыку в своем телефоне в это время. Размер такой «очереди» в Call-центре имеет свои технологические ограничения и если желающих дозвониться абонентов слишком много, а операторов (каналов обслуживания) слишком мало, то очередь переполняется и никакие другие абоненты просто не могут дозвониться по указанному номеру телефона (слышат короткие гудки «Занято»).

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

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

Человеческий мозг, находясь вне конкуренции в качестве универсального средства принятия решений, тем не менее, часто уступает другим инструментам при принятии специфических решений. В качестве примера можно известную игру в 2003-м году чемпиона мира по шахматам Гарри Каспарова с компьютерной программой X3D Fritz, запущенной всего лишь на одном компьютере с четырьмя процессорами Pentium 4 Xeon (почти PC). Как известно, состязание состояло из четырех игр, в двух из которых была ничья, в одной победил Каспаров и в одной победил X3D Fritz. Т.е. компьютерная программа, в основе которой лежат математические алгоритмы, не уступила человеческому мозгу в принятии решения «Какой сделать следующий ход, чтобы выиграть партию?».

Интересен ответ Каспарова на заданный ему после игры вопрос:

Журналист: Вы согласны с утверждением одного из международных гроссмейстеров, который сказал, что человек всегда умнее машины?

Каспаров: Матчи против машины имеют свою специфику. Ты находишься в постоянном напряжении. Ошибаться недопустимо, поскольку человек может тебе простить оплошность, а программа — нет.

Если посмотреть философски на этот пример, то в нем, на самом деле, «человеческий мозг» соревновался в принятии решений, не с «компьютерной программой», а с другим «человеческим мозгом» — мозгом создателей этой программы. Иначе говоря, с одной стороны находился человек с уникальными врожденными способностями принятия решений определенного плана, а с другой – человек без таких способностей, НО вооруженный аналитическим аппаратом для принятия решений (математические алгоритмы, компьютерные программы, базы знаний и др.). В итоге оказалось, что аналитический аппарат уравновесил их шансы в принятии правильных решений.

Об аналитическом аппарате для принятия решения и пойдет речь далее.

Общая схема процесса принятие решения

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

РЕШЕНИЕ (в психологии) – формирование стратегий и последовательности действий для достижения цели, основанное на избирательных мыслительно-поисковых актах и преобразовании субъективных смыслов.

РЕШЕНИЕ (в экономике) — способ, образ экономических действий государства, регионов, предприятий, фирм, который избирают их руководители в результате анализа вариантов, исходя из поставленных целей и с учетом наличия ограниченных ресурсов. Проект решения вырабатывается системными аналитиками, а утверждение решения после рассмотрения производится лицами, принимающими решения.

РЕШЕНИЕ (в математике) — 1. Выбор одной или нескольких альтернатив из множества возможных (вариантов решения). 2. Процесс (алгоритм) осуществления такого выбора.

Как видим, во всех трех определениях есть два основных понятия: цель и альтернатива (вариант решения). Эти же два понятия являются ключевыми понятиями процесса принятия решения. В общем виде процесс принятия решения может быть представлен следующим образом.

Этапы 1-3 и 6 представляют из себя плохо формализуемые процессы, происходящие в глубине человеческого разума или, того хуже, организационных структур. Например, невозможно просчитать, что будет двигать человеком в описанной ситуации. Вполне возможно, что на этапе определения целей индивидуум решит, что будет лучше, если он не придет на это совещание, сославшись на пробки, т.к. он знает, что решения, которые должны быть приняты на этом нем, очень рискованные и он не хочет, чтобы его подпись фигурировала в протоколе в пользу одного из них. Равно как этап 6 может включать в себя массу неформальных мероприятий, интриг, направленный на претворение принятого решения в жизнь.

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

Ниже рассмотрены отдельные аналитические методы, разбитые на четыре группы:

«Простые» методы принятия решений

«Визуальные» методы

К «визуальным» методам принятия решений можно отнести инструменты, при помощи которых анализируемая ситуация представляется в виде «наглядных» схем, матриц, диаграмм и др. Как правило, существует описание метода, включающее в себя способ заполнения соответствующей наглядной схемы и алгоритм принятия решений в зависимости от полученного результата. Таких методов существует много. Каждый из них ориентирован на решение определенных групп задач, например, задач стратегического планирования деятельности организации. С этими методами можно подробно ознакомиться в литературе по менеджменту и сайтах консалтинговых компаний – их создателей. В качестве примеров «визуальных» методов приведем «Матрицу BCG» (Бостонская матрица) и «SWOT-анализ».

Бостонская матрица

Категории решений: Решения в маркетинге по управлению продуктовым портфелем организации.

Наглядное представление: Матрица 2×2, по осям откладываются доля рынка, темп роста рынка. Далее продукты компании оцениваются с точки зрения этих двух параметров и помещаются в виде точек в эту матрицу.

Алгоритм принятия решений: В зависимости от попадания продукта в одну из четырех областей матрицы рекомендуется определенный набор действий в отношении этого продукта (см. на схеме выше).

SWOT-анализ

Категории решений: Стратегические решения для организации и индивидуума.

Наглядное представление: Матрица 2×2, по осям откладываются зоны относительно анализируемой организации (внутренняя и внешняя) и вид влияния на нее (положительное и отрицательное). Далее по полученным четырем категориям матрицы распределяются влияющие на организацию факторы и явления.

Ниже приведен пример заполнения матрицы для производителя автомобилей.

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

Сравнение альтернатив по критериям

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

Включает в себя следующую последовательность действий:

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

Более наглядно пример применения данного метода показан на схеме ниже.

Деревья решений

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

Проще всего проиллюстрировать идею метода деревьев решений на примере. Пусть сотрудник Антон работает в компании X. Компания X предлагает Антону сдать экзамен для получения сертификата по технологии Y. Компания не желает оплачивать обучение Антона, но готова предоставить ему время и на обучение и на самоподготовку в пределах рабочего дня. Компания X желает замотивировать Антона и обещает разовую премию в размере 2000$ в случае успешной сдачи экзамена и вычесть из зарплаты 500$ в случае провала на экзамене в счете рабочего времени, потраченного на подготовку. У Антона есть возможность пройти обучение, заплатив за это 1000$ собственных средств, в этом случае его шансы на успешную сдачу экзамена равны 80%. В случае самостоятельной подготовки его шансы на успех равны 50%. Антон имеет исключительно финансовую мотивацию для сдачи экзамена.

Антону необходимо принять следующие решения. Воспользоваться ли предложением компании и сдать экзамен или нет? Если сдавать экзамен, то стоит ли проходить обучение?

Описанная ситуация может быть смоделирована при помощи дерева решений, представленного ниже.

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

Так в исходной точке 1 Антон принимает решение сдавать или не сдавать экзамен, а затем в точке 2, если экзамен решено сдавать, он принимает решение проходить или не проходить обучение. В случае сдачи экзамена после обучения его шансы на успех возрастут (исход А) по сравнению со сдачей без обучения (исход B).

Расчеты для обоснования решений в точках 1 и 2 начинаются с «листьев» дерева. Так, «стоимость» исхода А равна 500$ (+2000$ * 0,8 – 500$ * 0,2 – 1000$ за обучение). Стоимость исхода B равна 750$ (+2000$ * 0,5 – 500$ * 0,5). Очевидно, что в точке 2 Антон сравнив стоимость исходов A и B, предпочтет B, как более дорогой. В итоге стоимость решения в точке 2 будет равна стоимости выбранного исхода (750$). В точке 1 Антон сравнивает стоимость варианта 2 и C. Он выбирает 2, т.к. 750$ > 0$.

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

Диаграмма Исикавы

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

На представленной диаграмме прямоугольники 1-3 – главные факторы, влияющие на анализируемый показатель качества. Квадраты 4-10 – вторичные факторы, влияющие на главные. А цифры 11-26 отражают третичные факторы, влияющие на вторичные.

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

В следующих статьях мы рассмотрим математические, вероятностные и экспертные методы принятия решений.

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

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

В настоящей статье рассматриваются наиболее распространенные методологии и возможность использования их отдельных элементов для построения модели и показателей эффективности работы службы поддержки конкретной компании – первого этапа на пути создания или совершенствования эффективного клиентского сервиса.

Содержание

• Определение и границы процесса поддержки клиентов
• Модели процессов поддержки

  • Многоуровневая модель обработки обращений

    • Вариант 1. Одноуровневая обработка обращений
    • Вариант 2. Двухуровневая обработка обращений
    • Вариант 3. Трехуровневая обработка обращений
  • Управление предоставлением ИТ-сервисов (ITSM)

    • Соглашение об уровне сервиса (SLA)
    • Основные понятия ITSM в процессе обработки обращения
• Мониторинг эффективности процессов поддержки
• Заключение

Определение и границы процесса поддержки клиентов

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

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

• основные и вспомогательные бизнес-процессы
• основные средства для обеспечения сервисной деятельности
• специализированные информационные системы и оборудование (Service Desk, ПО Contact-центра и др.)
• персонал
• CRM-система, увязывающая информацию о предоставлении сервиса в общее хранилище данных по взаимоотношениям с потребителями, а также с другими ИС предприятия (ERP и др.)
• бизнес-процессы управления сервисной деятельностью, методики ее планирования и оценки эффективности
• соответствующий раздел стратегии компании, описывающий политику в области сервиса

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

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

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

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

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

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

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

Модели процессов поддержки

Многоуровневая модель обработки обращений

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

Вариант 1. Одноуровневая обработка обращений.

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

Плюсы такого подхода:

• Минимальное время решения проблем.
• Удобство общения для клиента.

Минусы:

• Высокие издержки, связанные с оплатой труда высококвалифицированных специалистов для решения типовых проблем.

Вариант 2. Двухуровневая обработка обращений.

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

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

Плюсы:

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

Минусы:

• Клиенту приходится общаться с разными сотрудниками поддержки, ждать соединения, объяснять проблему несколько раз.

Вариант 3. Трехуровневая обработка обращений.

Часто причины проблем клиентов могут быть как простыми, так и очень сложными. Примером могут быть проблемы абонента ADSL при попытке соединения с Интернетом, которые могут быть связаны как с неправильной настройкой модема, так и с характеристиками линии связи. Сложные проблемы часто не могут быть устранены ни специалистом 1-й линии, ни специалистом 2-й линии, т.к. требуют глубоких профильных знаний, доступа к соответствующему оборудованию и др. В этом случае обработка обращений ведется на трех уровнях.

1-й уровень, как и в двухуровневой модели – это специалисты средней квалификации, которые оказывают консультации и решают несложные проблемы (1). Если проблема не может быть решена на 1-м уровне, она передается на 2-й уровень (2). Специалист 2-го уровня – это диспетчер, универсальный специалист, который знаком со всем спектром возникающих проблем. Его задача ознакомиться с проблемой и спланировать ее решение с привлечением специалистов профильных служб – 3-й уровень. Он задает маршрут прохождения заявки на решение проблемы (в специализированной системе) между профильными подразделениями (3) и отслеживает ход ее выполнения. После чего, когда проблема устранена он либо закрывает ее, либо сообщает об этом специалисту 1-го уровня (4), который связывается с клиентом и просит убедиться, что проблемы действительно больше нет (5), после чего закрывает ее.

Плюсы:

• Возможность решения сложных проблем, требующих привлечения профильных специалистов.
• Оптимальное использование рабочего времени квалифицированных специалистов.

Минусы:

• Обработка обращений может занимать несколько часов или дней.

Ну и наконец, стоит напомнить о том, что обработка обращений может вестись без участия оператора.

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

Управление предоставлением ИТ-сервисов (ITSM)

В настоящее время широкое распространение и популярность получили различного рода «библиотеки лучших практик», в которых в обобщенном и формализованном виде содержатся наработки компаний в определенных «предметных областях». Например, PMBoK в области управления проектами, eTOM – типовые бизнес-процессы оператора связи, ITIL – устройство ИТ-службы предприятия и др.

В этом разделе мы рассмотрим отдельные идеи методологии по управлению ИТ-услугами (IT Service Management), являющейся центральной частью библиотеки ITIL. В ITSM описывается взаимодействие между ИТ-службой и остальными подразделениями какой-либо компании. В качестве основного элемента этого взаимодействия рассматривается ИТ-сервис – услуга, которая оказывается ИТ-службой и используется бизнес-подразделениями. Примеры ИТ-сервисов: поддержка работоспособности компьютеров, администрирование и поддержка учетной системы и т.п. При этом ИТ-служба и бизнес-подразделение рассматриваются как достаточно обособленные субъекты, которые в общем случае могут находиться и в разных компаниях (аутсорсинг ИТ-услуг). Более того, в методологии ITSM многие базовые идеи не являются специфическими для ИТ и применимы не только для ИТ-услуг, но и для описания взаимодействия между поставщиком и потребителем услуг в иных сферах. В частности, если в качестве поставщика сервиса «Поддержка клиентов» рассматривать службу поддержки банка, а в качестве его потребителя клиента этого банка, то мы получаем возможность воспользоваться отдельными инструментами ITSM для описания процессов универсальной поддержки клиентов этого банка или какой-либо другой компании.

Рассмотрим две такие «универсальные идеи» ITSM:

• Описание характеристик предоставляемой услуги в соглашении об уровне сервиса (Service Level Agreement) и процедура обеспечение соответствия услуги заявленным параметрам SLA.
• Модель обработки обращения клиента в службу поддержки и соответствующая терминология.

Соглашение об уровне сервиса (SLA)

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

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

В случае если в рамках бизнес-процесса происходит взаимодействие с внешними компаниями-поставщиками, то в качестве OLA для таких операций при расчете клиентских SLA выступает SLA поставщика.

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

Основные понятия ITSM в процессе обработки обращения

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

• Заявка на обслуживание – зарегистрированное обращение клиента в службу поддержки
• Инцидент – факт несоответствия продукта или услуги компании заявленным характеристикам
• Проблема – причина несоответствия продукта или услуги компании заявленным характеристикам, обычно связана с одним или несколькими инцидентами
• Событие – факт несоответствия параметров функционирования элементов инфраструктуры компании регламентным значениям (обычно автоматически генерируются системой мониторинга в случае ее наличия)
• Изменение – набор действий, направленных на изменение в инфраструктуре или бизнес-процессах компании
• Service Desk – служба поддержки, единая точка входа для обращений клиентов компании

На следующей картинке изображен пример обработки обращения в службу поддержки с использованием этой терминологии.

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

Все перечисленные выше сущности и взаимосвязи между ними создаются, хранятся и обрабатываются в специализированной информационной системе — Service Desk (иногда ее также называют Order Management или Trouble Ticketing). При этом функции системы Service Desk не ограничиваются поддержкой workflow по работе с обращениями за поддержкой. Также эти системы занимаются формированием базы знаний службы поддержки (на основании информации, собранной в процессе поиска решений проблем), хранением информации об инфраструктуре предоставления услуг, управлением ею и др.

Service Desk позволяет формировать аналитические отчеты по базе обнаруженных проблем, которые могут использоваться при принятии стратегических решений, направленных на оптимизацию бизнес-процессов, инфраструктуры компании и приводить к ее изменениям.

Мониторинг эффективности процессов поддержки

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

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

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

Это, несомненно, важные и нужные показатели, однако, называть их показателями эффективности вряд ли правильно. Например, каково «эффективное» среднее время разговора? Может быть, чем меньше — тем лучше – экономия на зарплате операторов!? Тогда как быть с ситуацией, когда в результате длительного 15-минутного разговора клиент приобрел ряд дополнительных продуктов или услуг, а в результате короткого 30-секундного разговора только задал несложный вопрос? Или каков «эффективный» уровень загруженности операторов? Может быть, 100% — ведь надо максимально «эффективно» использовать персонал!? Тогда как быть, если действительно «эффективные» люди не идут работать в условиях такой «эффективности»? Может быть, «эффективный» процент потерянных вызовов – стремящийся к нулю? Тогда как быть со случаями, когда уровень доступности телефонной службы поддержки целенаправленно снижается, чтобы «приучить» клиентов пользоваться инструментами самообслуживания (вэб-портал, IVR) с целью снижения издержек?

Приведенные выше примеры показывают, что такого рода показатели при всей своей важности не являются показателями «истинной эффективности», но могут и должны (!) использоваться при ее расчете.

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

Очевидно, что она нужна собственникам компании, т.к. если не будет поддержки клиентов, то не будет клиентов, а значит не будет и денег. Также она нужна самим клиентам, т.к. без поддержки будет проблематично пользоваться купленными ими продуктами и услугами. Сервисная поддержка нужна самим сотрудникам службы поддержки, т.к. если ее не будет, то они лишатся работы.

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

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

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

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

Также следует отметить, что цели могут иметь иерархическую структуру. Например, цель «увеличение прибыли» содержит в себе две подцели: «увеличение доходов» и «снижение издержек».

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

Исходя из такого определения, чтобы сделать что-то эффективно мы должны:

1. Сформулировать задачи этой деятельности в соответствии со стоящими целями.
2. Определить критерии соответствия того, что делается стоящим целям – ключевые показатели эффективности (КПЭ).

Например, задачами сервисной поддержки в данном случае могут являться:

• Для достижения цели «Снижение издержек»
  • Внедрение систем самообслуживания клиентов
  • Повышение производительности труда операторов за счет использования продвинутых систем распределения вызовов
• Для достижения цели «Повышение удовлетворенности сотрудников работой»
  • Внедрение продвинутой системы учета обработки обращений для оплаты по результатам
  • Оптимизация загрузки сотрудников

А показателями эффективности сервисной поддержки могут являться:

• Для достижения цели «Снижение издержек»
  • Средняя себестоимость обработки обращения
  • Доля обработки обращений в режиме самообслуживания
• Для достижения цели «Повышение удовлетворенности сотрудников работой»
  • Текучка кадров за месяц
  • Средняя субъективная оценка удовлетворенности сотрудника работой (информация может собираться путем анкетирования)

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

Ниже схематически показан описанный выше процесс определения показателей эффективности. Следует отметить, что задание показателей эффективности параллельно с планированием деятельности по ее повышению позволяет просчитать ее эффект заранее (путем оценки значений КПЭ «до» и «после») и в случае, если даже плановый результат оказывается не удовлетворительным пересмотреть ее или отказаться от нее вовсе.

КПЭ должно быть немного. Они должны отражать ситуацию в очень обобщенном виде, пригодном для представления топ менеджменту компании – в очень сжатом виде позволять понять «что происходит» — в этом их преимущество. Недостаток их в том, что они не позволяют понять «почему это происходит». Для этого предназначаются детальные «технические» метрики, которые отражают те или иные аспекты происходящих процессов. Состав технических метрик, детализирующих КПЭ, определяется сразу после определения самих КПЭ.

Технические метрики могут использоваться для:

• Расчета значений КПЭ. Например, КПЭ «Средняя себестоимость обработки обращения» может рассчитываться на основании значений метрик по формуле (Себестоимость обработки оператором + Себестоимость обработки на портале самообслуживания + Себестоимость обработки на IVR) / 3.
• Детализации значений КПЭ в процессе поиска причин отклонений. Например, в процессе анализа причин увеличения значения КПЭ «Средняя себестоимость обработки обращения» может быть обнаружено существенное снижение значения метрики «Процент обслуженных вызовов на 1-м уровне». Это означает, что по каким-то причинам высококлассные (и высокооплачиваемые) специалисты 2-го уровня вынуждены заниматься решением типовых задач. Дальше анализируется почему это происходит (например, переход на поддержку новых продуктов не сопровождался достаточным обучением операторов 1-й линии) и ищутся пути решения.

К техническим метрикам, несомненно, относятся и приведенные выше в качестве примера псевдо-КПЭ показатели работы Call-центра. Пользователями технических метрик в основном являются менеджеры среднего и нижнего звеньев, которые разбираются с проблемами, приводящими к аномальным негативным изменениям общих КПЭ.

Во избежание двусмысленности и связанной с этим возможности искажения значений КПЭ в регламентах организации должны быть четко зафиксированы методики измерения технических метрик и расчета значений КПЭ на их основе.

И, наконец, о том, как может использоваться собранная информация со значениями КПЭ и технических метрик – завершающая стадия анализа эффективности, которому посвящена данная статья.

Вот основные варианты использования собранной информации:

• Сравнений значений КПЭ через определенные периоды времени — Что происходит?
• Анализ абсолютных значений КПЭ и технических метрик — Почему это происходит?
• Сравнение значений КПЭ «до» и «после» планируемого преобразования – Что должно будет произойти? Что же произошло на самом деле?
• Сравнение значений КПЭ компании с аналогичными показателями компаний-конкурентов (при наличии такой информации) – Что происходит у нас по сравнению с тем, что происходит у наших конкурентов?

Согласитесь – весьма актуальные вопросы для любого менеджера!

Заключение

Мониторинг эффективности поддержки клиентов является частью более общего процесса мониторинга CRM, включающего себя помимо сервиса еще и процессы продаж, маркетинга и др. Показатели эффективности CRM, в свою очередь, входят в состав общей системы управления компанией на основе КПЭ.

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