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

Intelligent Enterprise: В ИТ‑среде очень часто поднимается вопрос о том, что целесообразнее — внедрять решение, состоящее из различных систем, или развивать монолитную систему. Этот вопрос должен быть интересен и бизнесу. Имеет ли место в бизнесе такая дилемма?

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

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

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

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

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

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

В итоге накапливается значительное количество подобных нюансов. Что касается бизнеса нашей компании, то у консультантов Accenture, с которыми мы работаем, на некоторых проектах порой уходило до одного месяца на сбор информации и до двух месяцев на ее очистку. Причем имеется в виду не известная проблема технической очистки по‑разному представленной, но одинаковой по содержанию информации, а как раз выяснение нюансов ее трактовки различными подразделениями компании. Кстати, деловые беседы с рядом ведущих консультантов позволили мне понять, что это общая для всех стран проблема. Отдельные подразделения компании смотрят на ее бизнес со своих позиций, и в каждом из подразделений может складываться чрезвычайно устойчивый и обособленный взгляд. То есть различия в трактовке данных в определенной степени объективны. Понимая это, западные компании пытаются решить проблему, специально организуя для этой цели различные мероприятия — обучение персонала, его ротацию и т. д. Те консультанты, кто успел поработать и в России, и в странах Восточной Европы, утверждают, что барьеры непонимания между менеджментом различных направлений на предприятиях в этих странах куда более заметны, чем в Западной Европе.

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

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

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

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

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

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

Каким способом целесообразно действовать, если речь идет о развитии информационной поддержки бизнеса средствами, не входящими в «штатный набор» модулей той или иной ERP‑системы? Ведь здесь можно идти разными путями — внедрять отдельные модули ИТ‑систем других производителей, разрабатывать ПО с помощью независимого инструментария или внутренних средств разработки тех или иных ERP‑систем…

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

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

Мы, не в последнюю очередь в связи с кризисными явлениями, в последнее время пошли по пути создания собственных разработок в области прогнозирования спроса, о чем нам с вами уже приходилось беседовать (см. Intelligent Enterprise, №5/2009 — прим. ред.). И поскольку теперь мы имеем определенный опыт подобного расширения нашей ключевой системы SAP ERP, могу кое‑что добавить к сказанному. Данные решения могут изначально создаваться как временные (хотя некоторые из них могут эксплуатироваться в течение длительного времени), и это совершенно нормально. Но усилия не будут напрасными по крайней мере по двум причинам.

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

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

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