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

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

Сергей Леонидович Иванов — кандидат технических наук, предприниматель, специализирующийся в области решения задач автоматизации и ИТ-консалтинга компаний туристического и гостиничного бизнеса (http://www.admiral.ru/ ~ivanov_sl). Ему можно написать по электронной почте: isl@nevsky.net

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

ИТ-консалтинг «там» и «тут»

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

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

И никто не называет эти услуги консалтинговыми. В обиходе утвердился термин «разработка технических предложений».

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

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

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

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

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

  • «Ну ладно, мы вас вежливо выслушали, теперь мы будем думать дальше, а вы свободны». При этом сам собою отпадает вопрос об оплате.
  • «Все, что вы сказали, нам не подходит (у нас своя специфика), и менять способы организации своей работы мы не намерены. Оставьте все как есть, но сделайте так, чтобы все работало намного эффективнее». Ну что ответить клиенту на последнее предложение?
  • «Неужели мы должны тратить такие деньги на эту автоматизацию, ведь и так весь персонал справляется со своей работой? Может быть, неэффективно, но ведь работают же!» Это второй по распространенности ответ.
  • «В принципе все, что вы сказали, интересно, но мы ничего покупать не будем. У нас есть знакомый студент, он ну просто о-о-о-очень умный и обещал все автоматизировать за 100 рублей за две недели». Кстати, это — самый распространенный ответ.
  • «Вы предлагаете нам комплексное решение, но у нас сейчас нет денег, к тому же нам нужно автоматизировать только маленький участок, а к комплексной автоматизации мы вернемся позже». Пояснения о том, что некомплексное решение как правило, неэффективно, обычно не помогают.
  • «Вы предлагаете типовые решения, а мы хотим иметь сугубо индивидуальную систему, чтобы мы продолжали работать, как привыкли, не меняя организацию работ. А почему разработка индивидуальной системы стоит таких денег? Ведь вон, ?1С? можно купить на рынке за 50 рублей...». Далее опять следует ссылка на знакомого умного студента.
  • «Комплектация техники, которую вы советуете приобрести, и фирма, которую вы рекомендуете, нам не подходят, так как в другой фирме, в той, что расположена в соседнем подвале, цены на комплектацию на два доллара ниже». Ссылки на гарантийное обслуживание, сервис, репутацию фирмы-поставщика, ее опыт никого не интересуют.

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

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

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

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

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

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

Национальные (и вненациональные) особенности...

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

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

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

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

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

...и «крутизна» ты моя, «крутизна»...

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

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

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

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

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

P. S. А может быть, мы в своих представлениях слишком идеализируем ситуацию «там»? Может быть, там, «у них», безалаберность, разгильдяйство и расточительность так же, как у нас, соседствуют с рациональностью, бережливостью и порядочностью в ведении дел? Может быть, и так...


Слово к Заказчикам

Глубокоуважаемые Заказчики! При покупке автоматизированных систем постарайтесь «не лопухнуться» и тщательно выбирайте как саму систему, так и фирму-разработчика.

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

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

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

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

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

Обратите внимание на порядок оплаты за сопровождение. Некоторые фирмы определяют стоимость каждого визита к заказчику и при каждом обращении к ним выставляют счет на оплату. Здесь есть один подводный камень: для получения большего заработка фирмам выгодно, если система работает нестабильно, если в ней регулярно проявляются ошибки. Мне лично больше по душе, когда сопровождающие фирмы фиксируют месячную стоимость сопровождения системы и далее пытаются уложиться в согласованную с заказчиком сумму. Именно так мы поступаем с нашей гостиничной системой — нам выгодно, когда она работает стабильно (меньше расходов и, следовательно, при фиксированной цене получается больше прибыль). Мы приходим, заменяем версии, отвечаем на редкие вопросы операторов. Однако начальство, видя стабильную работу, начинает задаваться вопросом: «А собственно, за что мы платим? Ведь все нормально работает». В этом случае приходится объяснять, что большую часть работ по сопровождению и модификации систем мы осуществляем путем их макетирования на своей технике, а не на реально работающих объектах. В настоящее время у нас функционируют макеты всех 17 систем, которые мы реально внедрили.

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

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

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

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

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

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

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

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

Поделитесь материалом с коллегами и друзьями