Заказная разработка — это индивидуальный пошив

Компания ФОРС - одна из самых известных на российском рынке заказных разработок. Кроме того, именно специалисты, работающие сейчас в ФОРС, более 20 лет назад осуществили первую в России инсталляцию СУБД Oracle. Константин Зимин беседует с генеральным директором компании ФОРС Алексеем Голосовым.

Родился 9 декабря 1955 г. В 1978 г. окончил Московский экономико-статистический институт, факультет прикладной математики. В 1983 г. окончил аспирантуру ВНИИ системных исследований Академии наук и защитил кандидатскую диссертацию по проектированию схем реляционных баз данных. Работал во ВНИИ системных исследований Академии наук, принимал участие в проекте по созданию экологической экспертной системы в Университете штата Арканзас (США). Опубликовал более 30 статей в научных изданиях. В 1991 г. вместе с бывшими коллегами по Институту системных исследований создал компанию ФОРС, бессменным генеральным директором которой является по сей день. С 1996 г. входит в состав совета директоров EOUG (Европейской группы пользователей Oracle) и программный комитет международных конференций EOUG. С 2001 г. отвечает за партнерскую программу EOUG. Владеет английским и французским языками. Мастер спорта по фигурному катанию. Женат, имеет двоих детей.

Intelligent Enterprise: Давайте начнем разговор с разработки систем на заказ. Какие причины приводят компании к необходимости заказной разработки? Ведь, казалось бы, типовые решения существуют практически для всех мыслимых задач. Где возникают задачи заказной разработки систем?

Алексей Голосов: Если речь идет о полномасштабной системе автоматизации управления, то, конечно, начинать разработку с нуля неправильно. Такая система будет существенно дороже и ее разработка будет довольно долгой. Где возникают заказные разработки? Например, мы разработали SCM-систему для компании ЮКОС. Мы делали ее больше года, и она оказалась достаточно дорогой, но при выборе мы не навязывали заказную разработку и предлагали сразу посмотреть на тиражные SCM-системы. Однако у заказчика оказалось достаточно много специфических задач. Более того, эта компания планирует внедрять стандартную ERP- систему. Но часто мы сталкиваемся с ситуацией, когда компании, использующие такие системы, например, как SAP R/3, не могут решить с ее помощью все свои задачи автоматизации. И это приводит к необходимости заказных разработок.

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

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

И SAP, и Oracle согласны, что определенная подстройка ERP-системы под бизнес-процессы заказчика возможна. Как правило, при этом речь идет о 20 - 30% не самых критически важных бизнес-процессов. С другой стороны, возможен вариант заказной разработки этой части функционала. Как определить ту грань, которая отделяет выбор: подстройка типовой системы или заказная разработка?

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

Возвращаясь к вопросу - с нашей точки зрения, необходимо начинать с определения бизнес-процессов, понять, какой процент типовых бизнес-процессов может быть закрыт стандартными системами с минимальными модификациями. Скажем, в Oracle E-Business Suite есть порядка 200 типовых процессов. Если это возможно, то надо, конечно, выбирать типовое решение, мы не сторонники писать все заново. Мы рекомендуем заказные разработки только в тех случаях, когда понимаем, что задачу нельзя решить стандартными средствами. Мы начинаем разговор с заказчиком с моделирования его бизнеса, а программирование возникает как следствие.

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

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

Нет, задачи интеграции не столь страшны. Более того, даже такой поставщик ERP-систем, как Oracle, на самом деле интегрировал свои системы, входящие в E-Business Suite. Модули для Oracle E-Business Suite разрабатывались отдельно и затем интегрировались с помощью Oracle Workflow. Главный вопрос в том, как разрабатывать. Если в разработку заложены правильные технологии, то их можно интегрировать. Наш подход состоит в том, что интеграцию нужно делать через Oracle Workflow как основной инструмент интегрирования различных систем и как инструмент описания потоков работ и бизнес-процессов. Oracle Workflow - это своеобразный технологический клей, с помощью которого мы можем объединять разные системы.

Более того, мы уже решили подобную задачу, когда интегрировали Oracle Collaboration Suite c нашей разработкой. Это было необходимо потому, что системы управления архивами документов в Collaboration Suite не было, и мы добавили необходимую функциональность и показали это решение на европейской конференции Oracle. Поэтому, в принципе, задачи интеграции решаемы. Хотя, конечно, лучше брать стандартные модули. Я думаю, что специалисты Oracle, когда говорят, что интеграции надо избегать, имеют в виду, что когда уже есть много различных систем, их интеграция - сложный, дорогостоящий и трудоемкий процесс. И с этим утверждением я согласен. Более того, на европейской конференции партнеров Oracle было несколько компаний, которые интегрировали свое решение с E-Business Suite. Например, в E-Business Suite сейчас нет функциональности для банковской области, но Oracle приветствует партнеров, которые интегрируют с этой системой свои банковские решения.

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

Одна из серьезных трудностей с заказными разработками состоит в том, что когда поставщик проводит внедрение западной тиражной системы, то он всегда может апеллировать к западному опыту построения бизнеса. При заказной разработке намного сложнее сказать заказчику, как делать правильно. Заказчики говорят: "Не надо нас учить, мы ведем свой бизнес вот таким образом, а если вы так хорошо понимаете суть нашего бизнеса, то почему вы пишете программы, а не занимаетесь этим бизнесом?" К чему это приводит? В каких-то случаях нам удается доказать, что мы правы, и в бизнес-процессы начинают вноситься изменения, но иногда мы не можем сделать так, как считаем правильным, поэтому вынуждены автоматизировать текущее положение вещей, то что есть. Потому что сложнее заставить компанию переделать бизнес-процессы под заказную разработку, чем под стандартную зарубежную ERP-систему .

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

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

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

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

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

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

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

Давайте вернемся к интеграции приложений. В прошлом году ФОРС стал Центром компетенции по интеграции приложений на основе Oracle Application Server. Однако мы очень редко слышим о проектах по интеграции разнородных приложений. Насколько подобные системы интересуют российские компании и в каких ситуациях?

Сейчас достаточно реальный спрос на подобные решения возникает в ситуациях, когда у компании уже есть отдельные разработки и приложения и необходимо увязать их в единую систему, сделать так, чтобы эти системы умели общаться, осуществлять обмен информацией. Причем речь идет об интеграции существенно различных приложений. В Министерстве по налогам и сборам мы интегрировали документооборот на Lotus Notes и архивы документов, которые изначально вообще не были связаны между собой. Еще один пример - интеграция разных систем документооборота внутри холдинга, создание единой системы, при том, что холдинг не хочет менять уже работающие прикладные системы. Возникали задачи интеграции данных из разных бухгалтерских систем, а также интеграции с биллинговой системой. Вот в этих случаях необходим Application Server, тем более что и Oracle Workflow является его компонентом. Для нас это естественная платформа. И с нашей точки зрения, серверы приложений - это не отдельный рынок, а просто часть проектов. Если компания начинает проект полномасштабного внедрения ERP-системы, то, скорее всего, такой задачи интеграции не возникнет. Хотя я знаю, что на первых внедрениях Oracle E-Business Suite нередко приходилось интегрировать с различными системами, например, с бухгалтерией, когда заказчики вели ее на "1С" и не хотели от нее отказываться.

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

Давайте поговорим о бизнес-аналитике. ФОРС достаточно давно занимается такими задачами. Вы считаете это направление перспективным, а рынок в России созревшим для BI-инструментов? В какие моменты "жизни" предприятия возникает необходимость в таких системах?

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

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

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

По моим наблюдениям, часто компании считают, что они сделали проект в области бизнес-аналитики, когда просто собрали данные из нескольких источников в одном хранилище и выдали консолидированную отчетность руководству…

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

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

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