B2B
Публикации
2009
Выбор ИТ-решения для бизнеса

Выбор ИТ-решения для бизнеса

Лицо Акулы Додсона выразило глубокую печаль.
- Ты не поверишь, Боб, - вздохнул он, - как мне жаль, что твоя гнедая сломала ногу. Мне очень неприятно это говорить, но место есть только для одного. Боливар выдохся, и двоих ему не снести.

''Дороги, которые мы выбираем'', О’Генри

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

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

ЦОД — центр обработки данных

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

Для чего бизнес передает право распоряжаться достаточно крупными бюджетами?

Обычно для оправдания этого поступка говорят о том, что использование именно этих информационных решений, внедрение сложных программно-аппаратных комплексов, систем интеграции существующих решений обязательно в итоге даст компании повышение эффективности бизнеса в целом, снижение общих затрат, приведет к повышению прозрачности и производительности. Рассматриваются, чуть ли не как панацея, всевозможные варианты: «только внедрив ERP/SCM/CRM/АБС систему

ERP — Enterprise Resource Planning System — Система планирования ресурсов предприятия.
SCM — Supply Chain Management — Системы управления цепями поставок.
SRM — Supplier Relationship Management System — системы управления взаимодействием с поставщиками.
АБС — автоматизированная банковская система.
BPMS — Business Process Management System — системы управления бизнес-процессами.
SOA - Service-oriented architecture – Сервис-ориентированная архитектура.
ESB – Enterprise Service Bus – сервисная шина предприятия.

можно поднять продажи», «только используя BPMS/SOA/ESB можно снизить затраты и повысить эффективность», «только правильное интеграционное, бэк-офсное, фронт-офисное решение позволит вам…».

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

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

- Бюджет на реализацию ИТ стратегии выделяется для улучшения бизнес-показателей (как правило, бюджет самого ИТ подразделения составляет 10-20% от запрашиваемых на развитие бизнес-потребностей сумм)

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

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

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

- Финансовые потери (иногда в сотни миллионов долларов) от фиксации убытков после неудачного внедрения

- Снижение удовлетворенности потребителей, производительности труда сотрудников из-за нарушения/усложнения бизнес-процессов

- Разочарования/недоверия/отказа от использования среди менеджмента и собственников компании вызванного «неправильным» внедрением/использованием в принципе, нужных инструментов

- Ухудшение конкурентной позиции компании за счет использования инструментов автоматизации для процессов компании, где их использовать не стоило, либо использования неподходящих инструментов

Как можно избежать таких проблем? Ведь решения по выбору средств автоматизации лежат в столь туманной, сложной области? Не сложнее, чем купить бензопилу! И для этого вовсе не нужно в тонкостях понимать, чем SOA отличается от ESB. Давайте подробнее рассмотрим несколько вопросов, на которые стоит ответить для себя в процессе осуществления такого выбора.

А есть ли вообще необходимость что-либо менять?

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

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

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

А есть ли понимание что должно получиться?

Не стоит пытаться заниматься внедрением любого решения, если нет четкого понимания самого процесса, того, как должны осуществляться работы, независимо от того, делаются ли они вручную, в MS Excel, на бумаге или с использованием информационной системы за 100 млн. евро. Бытует мнение, что все правильные решения уже заложены в референсных моделях дорогих западных (и не очень) системах. Даже если это так, какое (из возможных) решение стоит использовать? Кто научит сотрудников им пользоваться в их текущей деятельности (что не является синонимом обучения использования программы)? Кто убедит их в том, что это правильно (и лучше того, что у них есть сейчас)? Кто встроит это (наладит связь) решение в остальные процессы? Если у компании (ее сотрудников) нет четкого понимания процесса (в виде карт процесса, регламентов, инструкций), для которого подбирается инструмент. Если нет четких бизнес-требований к тому, что хотелось бы улучшить, то нет смысла искать ИТ-инструменты.

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

Docflow – описание жизненного цикла документа, правил и маршрутов его прохождения, процедур обработки, участвующих лиц.

Сотрудниками ИТ-подразделения совершенно разумно было принято решение, что это не порядок – каменный век. Все очень медленно, много ошибок, велики риски. Но есть решение, которое может все исправить мигом. Руководство согласилось с доводами ИТ, особо не вникая: «говорят надо, значит надо». И в бюджет развития были заложены деньги на приобретение лицензий, клиентских частей (по количеству сотрудников), сервера, обучения. Деньги были освоены. Ответственные отчитались в успешном обучении персонала и внедрении системы. Спустя полгода после начала эксплуатации выяснилось, что в систему не было заведено ни одного документа. Провал? Ничуть, не в нашей традиции так просто признавать свои ошибки. Компания увеличила штат всех подразделений для того, чтобы появились специальные люди (которых предварительно обучили), единственной задачей которых стало вносить документы в систему (потому что остальные заявляли, что работать с системой неудобно, сложно, непонятно) и осуществлять в программе действия с ними за товарищей, помогая и обучая их. Долгожданная победа? Вовсе нет. Специальные люди заявили, что работать в системе все равно нельзя, так как у сотрудников нет единого понимания, как должен происходить документооборот, а поэтому, за исключением самых простых, остальные документы в системе настроить не получается. А поэтому, сначала надо разработать (и согласовать со всеми) классификацию документов, договориться о том, какие документы целесообразно учитывать в системе, определить жизненный цикл этих документов, требования к ним, разработать и согласовать процедуры и только потом приступать к внедрению. Спустя примерно два года (в течение которых исправно платились деньги за сопровождение системы со стороны разработчика, зарплаты специалистам по документообороту в отделах, администраторам системы и баз данных и проч.) компания пришла к пониманию, что для нее больше подходит более дешевое и простое решение другого производителя.

А есть ли понимание как прийти к желаемому?

Наиболее часто бизнесу компании представителями ИТ-индустрии предлагается два варианта выбора:

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

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

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

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

А какая информация нужна для того, чтобы выбрать?

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

Что понимается под словом «детально»? В качестве плохого примера можно привести случай, когда крупная компания, имеющая филиалы более чем в 70 городах, формировала требования к системе учета и обслуживания клиентов во фронт-офисах. Первоначально список требований занимал около одной страницы текста и был написан одним из лучших специалистов клиентского отдела компании за полдня. Проведенный выбор показал, что фактически все решения, найденные ИТ-специалистами (а их было около 40) удовлетворяют этим требованиям. То, что стоимость решений колебалась в очень широком диапазоне (от нескольких десятков тысяч до нескольких десятков миллионов долларов и сроки внедрения от 3 до 19 месяцев), а также оценивался специалистами ИТ как системы нескольких (разных) направлений, насторожил руководство компании. Несмотря на то, что в своих предложениях практически все разработчики гарантировали успех, так как цена риска была велика, то было принято решение отложить выбор и попытаться разобраться в ситуации. В итоге было принято решение пригласить группу бизнес-аналитиков. Была проведена достаточно большая работа в течение трех недель: проведены интервью со специалистами всех заинтересованных подразделений, проведен анализ существующей регламентирующей документации, требований регулирующих органов, учетной политики компании, проведено согласование противоречивых позиций, проранжирована важность требований. В итоге появилось несколько документов, описывающих в разных форматах согласованные требования бизнеса. Перечислим наиболее важные из них: BRD - собственно описание требований (более 100 страниц), RFP - изложение требований для получения предложения от поставщиков решений, FSD - детальное описание некоторых

BRD – Business Requirements Document – Бизнес требования.
RFP – Request for Proposal – Запрос предложения.
FSD – Functional Specifications Document – Функциональная спецификация.

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

А какие критерии выбора?

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

TCO – Total Cost of Ownership – совокупная стоимость владения системой.
ROI – Return On Investment – Окупаемость инвестиций.
DCF – Discounted Cash Flows – дисконтированные денежные потоки.
RAROC – Risk-Adjusted Return on Capital – скорректированная на риск доходность капитала.

Причем прибыль должна быть рассчитана с учетом альтернативных сценариев развития. Под альтернативными сценариями стоит понимать расчет прибыли в двух случаях P1 – планируемая прибыль без учета внедрения решения, P2– планируемая прибыль с учетом внедрения решения. Тогда для каждого предлагаемого решения можно рассчитать показатель ROI:

ROIi = (P2i – P1 – TCO) / Ii

Где I – размер инвестиций, запрашиваемых на решение.

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

Если вспомнить пример из предыдущего раздела, то после длительного совместного (ИТ и бизнеса) анализа расчетов, проведения дополнительных консультаций и переговоров с разработчиками, была выбрана система с 64% готовности, которая была (первоначально) на 10% дороже своего конкурента.

Итого

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

- Заинтересованность во внедрении новой технологии должна идти от того, кто ее будет использовать (бизнеса)

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

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

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

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

- Правильные (нужные) технологии не всегда самые дорогие

- Внедрение новой технологии должно приносить дополнительные деньги, большие, чем TCO внедряемой технологии

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

Тульчинский Станислав tulchinsky@b2b-group.ru

О компании Услуги группы компаний Наши компетенции Сотрудничество Проекты Ответы на вопросы Контакты Наши презентации Рейтинг	На главную О компании Публикации Контакты B2B Публикации 2009 Выбор ИТ-решения для бизнеса Выбор ИТ-решения для бизнеса Лицо Акулы Додсона выразило глубокую печаль. - Ты не поверишь, Боб, - вздохнул он, - как мне жаль, что твоя гнедая сломала ногу. Мне очень неприятно это говорить, но место есть только для одного. Боливар выдохся, и двоих ему не снести. ''Дороги, которые мы выбираем'', О’Генри Большинство собственников и топ-менеджеров решают этот вопрос просто – есть главный по ИТ (начальник отдела, управления, директор, CIO – в зависимости от размера компании), он за все «это» и отвечает. Вот он пусть и выбирает, а то в этих ИТ-аббревиатурах голову сломать можно. Именно после такого решения, обычно, в компании появляется ИТ-стратегия, которую формирует именно главный от ИТ. В этой стратегии им определяется состав мероприятий для достижения поставленных целей – т.е. реализация стратегии. В этот список, обычно, входит все, что так или иначе относится к ИТ. От ковриков для «мышек» до информационных систем и прочих технических решений (например, построения Call-центров или ЦОД-ов) в зависимости от размеров и амбиций компании. На основании ЦОД — центр обработки данных этого плана мероприятий появляется им же сформированный бюджет для согласования с руководством и собственниками (так как обычно бюджет этот немаленький). А уж предложений на рынке автоматизации предостаточно. Были бы выделены деньги. Для чего бизнес передает право распоряжаться достаточно крупными бюджетами? Обычно для оправдания этого поступка говорят о том, что использование именно этих информационных решений, внедрение сложных программно-аппаратных комплексов, систем интеграции существующих решений обязательно в итоге даст компании повышение эффективности бизнеса в целом, снижение общих затрат, приведет к повышению прозрачности и производительности. Рассматриваются, чуть ли не как панацея, всевозможные варианты: «только внедрив ERP/SCM/CRM/АБС систему ERP — Enterprise Resource Planning System — Система планирования ресурсов предприятия. SCM — Supply Chain Management — Системы управления цепями поставок. SRM — Supplier Relationship Management System — системы управления взаимодействием с поставщиками. АБС — автоматизированная банковская система. BPMS — Business Process Management System — системы управления бизнес-процессами. SOA - Service-oriented architecture – Сервис-ориентированная архитектура. ESB – Enterprise Service Bus – сервисная шина предприятия. можно поднять продажи», «только используя BPMS/SOA/ESB можно снизить затраты и повысить эффективность», «только правильное интеграционное, бэк-офсное, фронт-офисное решение позволит вам…». Нет, не сочтите автора за ретрограда, который печатает эту статью на пишущей машинке «Ремингтон» 1874 года выпуска, а экономические расчеты до сих пор выполняет на счетах. Конечно же, автоматизация может принести те блага, которые сулят их производители. Но для этого стоит принять как аксиому: именно бизнес определяет важные для себя цели и сколько он готов заплатить за их достижение. Автоматизация пойдет впрок, если: - Предлагаемые выгоды лежат в области интересов бизнеса (никто же не предлагает снизить потребную емкость жесткого диска или оперативной памяти, все говорят именно о бизнес-выгодах) - Бюджет на реализацию ИТ стратегии выделяется для улучшения бизнес-показателей (как правило, бюджет самого ИТ подразделения составляет 10-20% от запрашиваемых на развитие бизнес-потребностей сумм) - ИТ-структура в компании - это сервисное подразделение, призванное поддерживать основной бизнес-процесс и помогать ему зарабатывать деньги путем предоставления востребованных им (бизнесом) ИТ-услуг. Если это так, то тогда принятие решения о том, что нужно бизнесу от ИТ для выполнения его основной цели (зарабатывать деньги), выбор качества ИТ-систем, принятие решения о том, что в итоге нужно выбирать и сколько допустимо заплатить, должно быть за бизнесом. В противном случае решение принимает не бизнес (ну уж точно не Ваш бизнес). А тот, кто принимает решения, руководствуется точно не Вашими целями. А поэтому, скорее всего, благие обещания превратятся в серьезные проблемы для Вашей компании: - Финансовые потери (иногда в сотни миллионов долларов) от фиксации убытков после неудачного внедрения - Снижение удовлетворенности потребителей, производительности труда сотрудников из-за нарушения/усложнения бизнес-процессов - Разочарования/недоверия/отказа от использования среди менеджмента и собственников компании вызванного «неправильным» внедрением/использованием в принципе, нужных инструментов - Ухудшение конкурентной позиции компании за счет использования инструментов автоматизации для процессов компании, где их использовать не стоило, либо использования неподходящих инструментов Как можно избежать таких проблем? Ведь решения по выбору средств автоматизации лежат в столь туманной, сложной области? Не сложнее, чем купить бензопилу! И для этого вовсе не нужно в тонкостях понимать, чем SOA отличается от ESB. Давайте подробнее рассмотрим несколько вопросов, на которые стоит ответить для себя в процессе осуществления такого выбора. А есть ли вообще необходимость что-либо менять? Прежде всего, стоит отметить, что далеко не всегда вообще имеет смысл внедрять ИТ- решение только потому, что оно хорошо у кого-то заработало или потому, что оно сейчас модно. Стоит определиться, а есть ли у вашего бизнеса в этом (внедрении, замене одного другим, интеграции, установке) текущие потребности или они будут в будущем? В чем смысл замены бензопилы только на том основании, что появилась ее новая (пусть и более производительная) модификация, если в старой Вас все устраивает? Тем более, нет никакого резона сразу же задумываться о выделении денег только потому, что ИТ-специалисты хотят купить что-то. По нескольким причинам. Во-первых, в каждой компании должны быть фрагменты бизнеса, которым излишняя систематизация и формализация процессов просто вредны. Чего может добиться компания, загнав в чрезмерно узкие рамки формализации ИТ-системы разработку стратегии и новых продуктов? Там, где конкурентным преимуществом для компании должна быть креативность, вариация, все то, что внедрением любой системы, ИТ-решения загоняется в рамки технического задания, алгоритмов и форм. Причем определить единый список элементов бизнеса, где технологизация вредна, для всех компаний невозможно. Очевидно, что для одних компаний нормой должен быть четкий, выверенный процесс, например, клиентское обслуживание в рознице, для которого любые вариации являются синонимом операционных рисков и убытков. Но не менее очевидно, что для других компаний тот же процесс клиентского обслуживания должен быть гораздо менее регламентированным и формализованным (например, для VIP-обслуживания). Во-вторых, в каждой компании есть достаточно много уже работающих решений. Они уже зарекомендовали себя, их качество и производительность, в целом, всех устраивают сейчас и будут устраивать завтра. Несомненно, они не идеальны, но стоят ли те результаты, которые принесет замена их на новые, тех денег, которые за них просят? Готовы ли люди, которые усиленно рекомендуют внедрение новой технологии предоставить развернутый бизнес-план этого мероприятия? Привести исчерпывающие цифры как по расходной части, включающей не только сумму покупки лицензий и внедрения, но и все сопутствующие затраты на неком промежутке времени (3-5 лет): затраты на сопровождение, обучение персонала, приобретение и сопровождение системного лицензионного обеспечения, инфраструктуры? Описать увеличение доходной части, которую обеспечит новое решение от текущего состояния: на сколько увеличатся финансовые показатели, возрастет ли прибыль, снизятся ли убытки, сократятся ли риски? И как итог – рассчитать возврат от инвестиций и принять на себя хотя бы часть ответственности (в виде итоговых бонусов, премий, отложенных платежей по договору) за получение этого результата, за цифры бизнес-плана. А есть ли понимание что должно получиться? Не стоит пытаться заниматься внедрением любого решения, если нет четкого понимания самого процесса, того, как должны осуществляться работы, независимо от того, делаются ли они вручную, в MS Excel, на бумаге или с использованием информационной системы за 100 млн. евро. Бытует мнение, что все правильные решения уже заложены в референсных моделях дорогих западных (и не очень) системах. Даже если это так, какое (из возможных) решение стоит использовать? Кто научит сотрудников им пользоваться в их текущей деятельности (что не является синонимом обучения использования программы)? Кто убедит их в том, что это правильно (и лучше того, что у них есть сейчас)? Кто встроит это (наладит связь) решение в остальные процессы? Если у компании (ее сотрудников) нет четкого понимания процесса (в виде карт процесса, регламентов, инструкций), для которого подбирается инструмент. Если нет четких бизнес-требований к тому, что хотелось бы улучшить, то нет смысла искать ИТ-инструменты. Можно привести пример неверного ответа на этот вопрос из практики большого финансового учреждения. Компания решила внедрять систему документооборота, не имея четкого понимания самой задачи «Документооборот». Документы, конечно же, как-то «жили» в компании. Договора, письма, решения, служебные записки согласовывались, уточнялись, подписывались. Все это происходило согласно сложившемуся некогда нестрогому порядку: каждый, кто нуждался в каком-либо решении, сам инициализировал разработку документа, определял его форму и содержание, организовывал его согласование, отслеживал движение, принятие и исполнение решения. Четкого процесса, классификации документов, требований, стадий жизни, docflow просто не было. Docflow – описание жизненного цикла документа, правил и маршрутов его прохождения, процедур обработки, участвующих лиц. Сотрудниками ИТ-подразделения совершенно разумно было принято решение, что это не порядок – каменный век. Все очень медленно, много ошибок, велики риски. Но есть решение, которое может все исправить мигом. Руководство согласилось с доводами ИТ, особо не вникая: «говорят надо, значит надо». И в бюджет развития были заложены деньги на приобретение лицензий, клиентских частей (по количеству сотрудников), сервера, обучения. Деньги были освоены. Ответственные отчитались в успешном обучении персонала и внедрении системы. Спустя полгода после начала эксплуатации выяснилось, что в систему не было заведено ни одного документа. Провал? Ничуть, не в нашей традиции так просто признавать свои ошибки. Компания увеличила штат всех подразделений для того, чтобы появились специальные люди (которых предварительно обучили), единственной задачей которых стало вносить документы в систему (потому что остальные заявляли, что работать с системой неудобно, сложно, непонятно) и осуществлять в программе действия с ними за товарищей, помогая и обучая их. Долгожданная победа? Вовсе нет. Специальные люди заявили, что работать в системе все равно нельзя, так как у сотрудников нет единого понимания, как должен происходить документооборот, а поэтому, за исключением самых простых, остальные документы в системе настроить не получается. А поэтому, сначала надо разработать (и согласовать со всеми) классификацию документов, договориться о том, какие документы целесообразно учитывать в системе, определить жизненный цикл этих документов, требования к ним, разработать и согласовать процедуры и только потом приступать к внедрению. Спустя примерно два года (в течение которых исправно платились деньги за сопровождение системы со стороны разработчика, зарплаты специалистам по документообороту в отделах, администраторам системы и баз данных и проч.) компания пришла к пониманию, что для нее больше подходит более дешевое и простое решение другого производителя. А есть ли понимание как прийти к желаемому? Наиболее часто бизнесу компании представителями ИТ-индустрии предлагается два варианта выбора: - Первый (подразумевается «правильный»): есть несколько профессиональных ИТ- решений, в референсных моделях которого уже учтены все «правильные» решения и действительно стоящие замечания бизнес-лидеров этого рынка. Поэтому не стоит изобретать свой «велосипед», достаточно ознакомится со списком клиентов компании-поставщика решения, чтобы понять, кто нужен. После этого надо по максимуму (в идеале вообще без изменений) внедрить тот продукт, который выбран, на основе рекомендаций его разработчиков. Причем изменения придется вносить в процессы компании, но это и к лучшему, так как они в компании не идеальны, а вот в системе заложено решение, которое работает у таких-то «китов» (при этом подразумевается, что у них процессы идеальны). Такой подход, со слов его сторонников, гарантирует не только правильность, но и быстроту, сравнительную дешевизну и минимизацию рисков. - Второй (подразумевается «неверный», в общем случае): взять и переделать какое-либо существующее решение (либо написать «под заказ» новое) под требования бизнеса компании. Такой подход, со слов его противников, не гарантирует правильности решения (ведь процессы компании не идеальны), но гарантирует длительность разработки, сравнительную дороговизну и почти не контролируемые риски. Казалось бы, выбор очевиден. Но, как говориться «дьявол в нюансах». Каждый из приведенных вариантов выбора строится на ряде допущений, которые принимаются, как само собой разумеющиеся. Но, вообще-то, они требуют отдельных доказательств. Например, кто сказал, что предлагаемые решения действительно идеальны, или они подойдут к бизнесу Вашей компании или ее персоналу? Не придется ли для их внедрения переделать всю компанию, не приведет ли это просто к изменению бизнеса? Ведь очевидно, что идеальный двигатель от Ferrari нельзя поставить на грузовичок, не переделав этот грузовик полностью. И что можно получить в итоге? Жалкое подобие Ferrari с микроскопическим кузовом для перевозок? При выборе информационного решения, особенно того, которое требует серьезных вложений, от которого может зависеть судьба всего бизнеса, нет одного очевидного решения. Примером неочевидности выбора «правильного решения» может служить история компании, которая осуществляла операции на финансовом рынке в определенном сегменте клиентов и операций. Этот сегмент был малоинтересен московским «грандам», делавшим свой бизнес в более массовых и доходных операциях, являясь там фактически монополистами. Компании разработчики выпускали бэк-офисные решения с учетом пожеланий своих крупных клиентов. Естественно, что решение, нужное для региональной компании в их предложение не входило. И даже заняться доработкой «за деньги» никто из них не хотел, считая неверным по соображениям целостности системы вносить такие изменения. Причем все наперебой убеждали руководителей, что нужно перейти на стандартное решение, которое будет более правильным, дешевым. Но, тогда бы пришлось отказаться от группы операций, которые приносили основную прибыль. Компании пришлось инвестировать в поиск, обучение своих разработчиков и самостоятельно доработать решение и самой сопровождать его в течение пяти лет самостоятельно, пока у разработчика «дошли» до этого руки (после этого они, конечно же, перешли на решение от поставщика). Но, эта «доработка» фактически кормила всю компанию в течение этого времени, позволяя быть самой крупной и успешной (с точки зрения размера прибыли) в своем регионе финансовой компанией. А какая информация нужна для того, чтобы выбрать? Наверное, это самый сложный момент для любого менеджера, когда возникло понимание того, что надо менять, какие результаты хочется получить на выходе. Как уже было замечено: любое ИТ-решение это только инструмент для задач бизнеса. Каждый бизнес должен подбирать инструменты по себе. Молоток, который подошел кузнецу, явно будет не в пору часовщику. И это очевидно. Но, какой именно инструмент нужен, ведь все эти названия - китайская грамота для большинства менеджеров. Конечно, не стоит даже пытаться самому в этом разобраться (ну разве только ради собственного любопытства). Достаточно правильно сформулировать задачу ИТ-специалистам. Формулировка задачи должна исчерпывающе описывать с точки зрения бизнеса (пользователей) какую задачу и как именно нужно решить. Вся проделанная ранее работа по выяснению того, что именно должно быть улучшено, какой процесс должен получиться в результате, какие цели преследуются должно быть сформулировано в требованиях специалистам ИТ. Для этого совершенно точно не стоит разбираться с тем какие именно решения, в каких сочетаниях нужно искать. Это сделают специалисты за вас. Но для этого нужно предоставить детальное описание требований бизнеса. Что понимается под словом «детально»? В качестве плохого примера можно привести случай, когда крупная компания, имеющая филиалы более чем в 70 городах, формировала требования к системе учета и обслуживания клиентов во фронт-офисах. Первоначально список требований занимал около одной страницы текста и был написан одним из лучших специалистов клиентского отдела компании за полдня. Проведенный выбор показал, что фактически все решения, найденные ИТ-специалистами (а их было около 40) удовлетворяют этим требованиям. То, что стоимость решений колебалась в очень широком диапазоне (от нескольких десятков тысяч до нескольких десятков миллионов долларов и сроки внедрения от 3 до 19 месяцев), а также оценивался специалистами ИТ как системы нескольких (разных) направлений, насторожил руководство компании. Несмотря на то, что в своих предложениях практически все разработчики гарантировали успех, так как цена риска была велика, то было принято решение отложить выбор и попытаться разобраться в ситуации. В итоге было принято решение пригласить группу бизнес-аналитиков. Была проведена достаточно большая работа в течение трех недель: проведены интервью со специалистами всех заинтересованных подразделений, проведен анализ существующей регламентирующей документации, требований регулирующих органов, учетной политики компании, проведено согласование противоречивых позиций, проранжирована важность требований. В итоге появилось несколько документов, описывающих в разных форматах согласованные требования бизнеса. Перечислим наиболее важные из них: BRD - собственно описание требований (более 100 страниц), RFP - изложение требований для получения предложения от поставщиков решений, FSD - детальное описание некоторых BRD – Business Requirements Document – Бизнес требования. RFP – Request for Proposal – Запрос предложения. FSD – Functional Specifications Document – Функциональная спецификация. наиболее важных для компании алгоритмов, функций, процедур, а также составлена скоринговая модель для осуществления формального (на основе набранных баллов) выбора того, какое решение подходит больше. В итоге минимальный порог достаточности (решение должно удовлетворять не менее 60% ключевых требований) прошло только два решения. Одно из них удовлетворяло на 67% заявленным требованиям, а другое на 74%. Вероятность выбора по первоначальным требованиям этих решений была отрицательной. Так как это были два самых дорогих предложения в списке. А какие критерии выбора? Обычно практикуется подход по оценке непосредственной стоимости решения. В него включают стоимость лицензий, внедрения, другими словами, разовые прямые затраты на приобретение и установку решения. Иногда еще принимают во внимание стоимость последующего сопровождения. Гораздо реже компания пытается определить ТСО всего решения, учитывая также косвенные затраты, которые понесет организация на внедрении решения. В них могут входить затраты на обучение персонала, приобретение элементов инфраструктуры, системного программного обеспечения, найм дополнительного персонала, последующую доработку и проч. Это только расходная часть проекта. Обычно любой крупный (да и не очень крупный) проект в области информационных решений требует существенных инвестиций финансов, затрат человеческих ресурсов, занимает достаточно много времени. Руководство компании возлагает на него большие надежды (как правило, в области дальнейшего взрывного развития компании). Поэтому для оценки и выбора такого проекта расчета только ТСО (которое могут предоставить ИТ специалисты) явно недостаточно. Необходим расчет (как и для любого инвестиционного проекта) показателя ROI. TCO – Total Cost of Ownership – совокупная стоимость владения системой. ROI – Return On Investment – Окупаемость инвестиций. DCF – Discounted Cash Flows – дисконтированные денежные потоки. RAROC – Risk-Adjusted Return on Capital – скорректированная на риск доходность капитала. Причем прибыль должна быть рассчитана с учетом альтернативных сценариев развития. Под альтернативными сценариями стоит понимать расчет прибыли в двух случаях P1 – планируемая прибыль без учета внедрения решения, P2– планируемая прибыль с учетом внедрения решения. Тогда для каждого предлагаемого решения можно рассчитать показатель ROI: ROIi = (P2i – P1 – TCO) / Ii Где I – размер инвестиций, запрашиваемых на решение. И вообще, все подходы применимые к анализу инвестиций – сравнение DCF, RAROC, анализ периода окупаемости, анализ «инвестиционной ямы», управление графиком платежей (объективно обосновывая перед заказчиком требования по отсрочкам, графику платежей) и проч. вполне применимы для анализа такого рода проектов. Во-первых, они позволяют анализировать проект (осуществлять выбор) с точки зрения понятной (и единственно правильной!) для бизнеса. Во-вторых, они заставляют двух человек (ИТ-специалиста, который осуществляет технический выбор решения и представителя бизнеса, для которого ищется это решение) ответственно взглянуть на свой выбор. Так как заявляемые величины прибыли, ТСО, ROI должны быть внесены в качестве показателей в их контракты. Если вспомнить пример из предыдущего раздела, то после длительного совместного (ИТ и бизнеса) анализа расчетов, проведения дополнительных консультаций и переговоров с разработчиками, была выбрана система с 64% готовности, которая была (первоначально) на 10% дороже своего конкурента. Итого Для того, чтобы выбираемая технология все же в итоге решала задачи своего владельца, помогала ему в его работе, необходимо опираться на следующие принципы: - Заинтересованность во внедрении новой технологии должна идти от того, кто ее будет использовать (бизнеса) - Технологии не должны подменять понимание всех тонкостей бизнеса. Попытка заменить принципы своего бизнеса на «типовое» решение, которое предлагает разработчик технологии, приведет к тому, что, не разобравшись в особенностях и проблемах своего бизнеса, вы будете вынуждены устранять еще большее количество тех же проблем, порожденных старыми причинами, и новой, чужой технологией - Технологии должны поддерживать бизнес, а не управлять им, бизнес не надо корректировать только по причине появления новой технологии - Технологии должны поддерживать людей, для технологии не должно быть основной цели в их простой замене, потому что добавленную стоимость создают профессионализм и одаренность людей - Инструменты и технологии должны решать конкретные задачи, поиски панацеи - «серебряной пули», способной решить все проблемы, тщетны - Правильные (нужные) технологии не всегда самые дорогие - Внедрение новой технологии должно приносить дополнительные деньги, большие, чем TCO внедряемой технологии Те, кто платит деньги (бизнес) не должны передавать свое право выбора, принимая на веру те громкие слова, которые им говорят. Очевидно, сама тема ИТ и технологий сложная и нет возможности в ней разобраться людям, которые заняты совершенно другими задачами – они деньги зарабатывают. Выбор ИТ-решения должен быть инвестицией в развитие, а любые инвестиции должны зарабатывать новые деньги для компании. Правильнее отнестись к такому выбору, как к принятию решения о сложном инвестиционном проекте, в котором ИТ-решение только составная часть. А ответственность за его поиск и выбор делегирована ИТ-подразделениям и происходит под контролем бизнеса, отвечающего за весь проект. Нельзя рассматривать вложение в ИТ как отдельный проект, так как он становиться просто приобретением дорогих инструментов, (если только Вы не собираете коллекцию). Очень сложных, временами, но все же только инструментов. Просто инструменты самостоятельно не смогут сделать того, чего за них обещают продавцы и производители. Они могут не подойти для тех, кто их должен использовать. Они могут не соответствовать целям и стратегии компании. И при этом быть блестящими разработками талантливых людей. Тульчинский Станислав tulchinsky@b2b-group.ru
mail@b2b-group.ru
Создание сайта — студия BlackBox	Copyright © b2b-group При копировании информации, ссылка на источник обязательна. Полное либо частичное копирование информации с этого сайта на другие ресурсы разрешено только при наличии видимой ссылки на наш сайт.