Содержание Вернуться к изданию

Искусство управлять №1-2017, 02.05.2017

Слово Директора

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

name

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

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

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

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

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

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

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

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

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

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

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

Ваш А.Б. Гершкович,
Президент компании «ЭЛКОД»

Читать далее

Изучая и анализируя тему возможных аспектов принятия управленческих решений, редакция журнала «Искусство управлять» посчитала вполне естественным и логичным обратиться к маркетологу, ведущему авторского семинара «Принятие решений» и одному из самых известных магистров игры «Что? Где? Когда?» – Максиму Поташеву.

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

name

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

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

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

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

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

– В 2016 году Вы выпустили в соавторстве с Павлом Ершовым книгу «Путь решения», в которой предлагаете алгоритм поиска и принятия решений. Давайте поговорим подробнее об этом. С чего начать поиск решения?

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

Что такое правильное решение?

Мы считаем решение правильным, если:

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

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

Но если проблему всё же удалось выявить, ее нужно зафиксировать, дать ей первичное описание, провести экспресс-анализ. Интересно, что уже на этой ступени можно найти ценное решение, которое называют quick win или быстрая победа.

– А как понять, какую именно проблему нужно решать?

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

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

– Когда проблема определена, как к ней подступиться? С чего нужно начинать поиск решения?

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

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

– Максим, какая информация необходима для принятия управленческих решений? Какие могут быть источники этой информации?

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

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

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

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

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

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

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

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

– Кто в итоге должен взять на себя ответственность, чтобы сказать «стоп, данных собрано достаточно»?

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

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

– Расскажите, пожалуйста, о важности структурирования задач в процессе поиска решения. Что не должно ускользнуть от внимания управленцев?

– Чтобы данные работали на нас, а не мешали в поиске верного решения, нужно правильно их собрать. Мы предлагаем использовать принцип МЕСЕ, который, по нашему мнению, является самым важным инструментом на этапе структурирования. Сам термин МЕСЕ (Mutually Exclusive, Collectively Exhaustive) в переводе звучит как «взаимно исключающие, совместно исчерпывающие». Его суть заключается в том, что все данные нужно разбить на какие-то категории, чтобы, с одной стороны, они не пересекались, а с другой стороны, покрывали весь объем допустимой области. Давайте разберемся на примере.

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

– Можно самостоятельно овладеть умением применять принцип МЕСЕ или этому должен научить специалист?

– Помните персонажа Мольера, который вдруг выяснил, что «всю жизнь говорил прозой»? Так вот здесь та же самая история: мы постоянно используем некоторые методы в своей практике, но даже не задумываемся о том, что они действенны. Овладеть некими умениями несложно, все инструменты, которые мы описываем в книге, просты, но они требуют некой осознанности. Именно когда мы осознаем, как и что делаем, – мы начинаем работать гораздо эффективнее.

– Вы говорите, что важно научиться замечать закономерности, в том числе неявные, и что этот навык приходит с опытом. О каком опыте идет речь – негативном или положительном?

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

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

name

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

– Какому решению нужно отдавать предпочтение? Если я Вас правильно поняла, порой решению достаточно быть всего лишь быстрым. Не сыграет ли такой принцип против управленцев / компании? Ведь быстрое – это, как правило, легкое, то, над чем не нужно долго работать.

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

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

Но на этапе выбора решения ситуация принципиально другая. Мы должны делать выбор с холодной головой, дистанцироваться от эмоций. Наиболее известные приемы – «моральная алгебра» Бенджамина Франклина, когда мы делим листок пополам и составляем сравнительную таблицу плюсов и минусов решения; квадрат Декарта (см. Рис. 1). Менее известные – Правило 10/10/10, принцип «Что стал бы делать ваш преемник?», Правило коричневых М&М, Формула доверия, которую прозвали формулой Поташева за мое к ней пристрастие. У этих методов единый принцип действия: мы разбиваем решение на составляющие, суммируем плюсы и минусы и на выходе получаем некую объективную оценку.

– Означает ли это, что в бизнесе для развития нужно стремиться предлагать нестандартные решения?

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

name

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

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

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

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

– Максим, как, по Вашему мнению, лучше выстраивать процесс принятия решений в компании – своими силами или прибегать к помощи стороннего консультанта?

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

– Применяя Ваш алгоритм принятия решений, нужно ли какому-либо блоку уделить больше внимания?

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

– Какие советы Вы можете дать управленцам, которые желают научиться принимать верные решения?

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

– А это должна быть индивидуальная работа или только работа в команде? От чего больший положительный эффект?

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

Беседу провела Татьяна Маркина,
редактор ООО «ЭЛКОД»

Читать далее

Максим Поташев

Магистр телеигры «Что? Где? Когда?», математик, маркетолог, управляющий партнер «R&P consulting».

ЭТАПЫ ВНЕДРЕНИЯ ERP-СИСТЕМЫ

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

КЛЮЧЕВАЯ РОЛЬ ЭТАПА «МОДЕЛИРОВАНИЕ»

Исторически заказчиков информационных систем можно поделить на три условные группы:

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

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

name

Если вернуться к условному разделению на группы, то правы представители и второй, и третьей групп. Чтобы успешно внедрить информационную систему, нужно понять, куда мы целимся. Для этого необходимо сначала собрать все требования, а затем придумать и описать, как они должны быть реализованы. Именно для этих целей и служит ТЗ. Важно отметить, что часто сложным является даже не проектирование, а просто сбор требований пользователей. В проектах не всегда явно выделяют отдельный этап сбора требований, хотя он является базой для всего и далеко не всегда легко выполним. Существуют даже международные руководства о том, как выявить все требования к информационной системе (Business Analysis Body of Knowledge, сокращенно – BABoK). Что же тут сложного? Когда речь идет о внедрении информационной системы для бухгалтерского и налогового учета, значительная часть требований достаточно понятна, они определены законодательством. Хотя даже в этом случае есть немало пространства для творчества: в одних организациях бухгалтерский учет ведется подробно, аккуратно даже для использования во внутренних целях; в других его ведут максимально простым способом и только для целей сдачи отчетности государству.

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

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

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

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

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

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

ДЛЯ ЧЕГО НУЖНО МОДЕЛИРОВАНИЕ?

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

Почему подрядчик не может дать точную оценку проекта, если есть полноценное техническое задание?

Если бы каждая конкретная фирма с конкретным финансовым директором или ИТ-директором не была уникальна вне зависимости от сферы деятельности, а любые, кроме совсем общепринятых, операции не выполнялись так, как удобно начальству или как сложилось исторически, – то да, ТЗ было бы достаточно. Но каждый раз, когда после ознакомления с документацией наши специалисты начинают задавать вопросы, обнаруживается море нюансов, которые и за день не зафиксируешь. И это если у нас намечается проект по какому-то одному контуру. А если их несколько?!

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

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

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

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

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

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

По итогам проведения моделирования мы с вами должны:

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

И хотя стоимость данного этапа порой может доходить до 30% бюджета всего проекта, вы первые, кто получит выгоду от его проведения и в финансовом, и в функциональном плане.

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

БЕССОЗНАТЕЛЬНОЕ И ВНЕДРЕНИЕ ERP-СИСТЕМ

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

«РУКИ» ЕСТЬ, А П