In English

"Аплана": Мы решаем проблемы бизнеса

05.02.2003
Издание: Сетевой
Динамично растущая компания "Аплана", входящая в Группу компаний "АйТи", образована год назад на базе Центра Заказных Разработок ПО "АйТи". Сегодня она предлагает широкий спектр высококачественных услуг в области разработки и интеграции заказных программных систем для корпоративных заказчиков в России и за рубежом. Специалистами компании реализовано более 100 проектов разного объема -от небольших специализированных систем до проектов масштаба крупного предприятия. В числе ее заказчиков ЦБ РФ, "Газпром", "Комстар", Procter&Gamble, Systran и многие другие отечественные и зарубежные компании. Сходную с нашей задачу "Аплана" решила для российского представительства компании ОТИС, и мы по ходу изложения будем ссылаться на этот проект (краткое его описание представлено во врезке на с. 52).

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

О СТОИМОСТИ, ОБЪЕМЕ И ГОТОВЫХ НАРАБОТКАХ

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

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

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

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

Однако "Аплана" не привязывается к набору готовых типовых проектов, а каждый раз решает конкретную задачу: если подходящие наработки есть, они используются, если нет - работа начинается с "чистого листа". Нет и ограничений по используемым технологиям, так что разработка может быть выполнена для самого причудливого "зоопарка" имеющегося ПО с применением именно тех программных средств, которые здесь подходят наилучшим образом. Так, проект для ОТИС был построен на базе установленных у заказчика MS Exchange, MS US и Oracle, к которым потребовалось добавить несколько интерфейсных и стыковочных модулей. Специалисты "Апланы" владеют и достаточно традиционными, и самыми современными технологиями, имеют опыт построения интернет-порталов, Web-сервисов на разных платформах и т.д.

ОБЩИЙ ЯЗЫК

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

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

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

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


ПРЕДЛОЖЕНИЕ И ЗАДАНИЕ

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


В более сложных ситуациях, когда параметры проекта не могут быть достаточно точно определены без дополнительного исследования, "Аплана" предлагает заказчику проведение такого исследования и подготовку детального технического задания (ТЗ), которое оформляется в соответствии с ГОСТом. Эта работа выполняется по отдельному проекту и, естественно, за отдельную плату.

Готовое ТЗ в принципе является отчуждаемым продуктом: заказчик может забрать его из "Апланы" и передать для внедрения в другую фирму, а у самой "Апланы" есть несколько проектов, выполненных по "чужим" ТЗ. Но обычно заказчик оставляет ТЗ в "Аплане" и заключает договор с ней.


КОМПЛЕКСНЫЙ ПОДХОД И КОНСАЛТИНГ

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

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

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


РАЗРАБОТКА И ОПЫТНАЯ ЭКСПЛУАТАЦИЯ

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

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

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

Разработка заканчивается тестированием и документированием. Документацию небольших проектов в "Аллане" часто пишут в собственном формате, если, конечно, заказчик не настаивает на ее оформлении согласно ГОСТу. Это снижает затраты и не приводит к ухудшению результата: документация содержит полную информацию о программе, причем в более обозримом виде, чем было бы при использовании стандартных шаблонов. Применение стандартов начинает играть положительную роль только в крупных и, может быть, средних проектах, а в мелких лишь увеличивает накладные расходы: как выразил это исполнительный директор "Апланы" Михаил Македонский, "любая сложность должна быть оправдана".

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

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


КОГДА СИСТЕМА СДАНА

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

Обычно заказчикам нужно не только эксплуатировать разработанные для них программы, но и развивать их. Системы, построенные "Апланой", являются полностью отчуждаемыми, т.е. развивать их дальше может не только компания-разработчик, но и сам заказчик, а также третья фирма. Так, разработанный "Апланой" Web-портал агентства по найму NJ Club некоторое время развивали специалисты заказчика, а сейчас он стал частью более масштабного проекта,

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

ВОЗВРАЩАЯСЬ К ЗАДАЧЕ

Итак, мы описали жизненный цикл проекта. Что же будет представлять собой сам проект?

О нем можно сказать не очень много. Вполне вероятно, что специалисты "Апланы" предложили бы нашей мебельной фабрике решение на основе ее собственного ПО - почтового сервера, сервера баз данных и Интернет-сервера, - так же, как это было сделано в проекте для ОТИС. В задаче ничего не сказано о том, какое именно серверное ПО используется на предприятии. Если это не те же продукты, что в ОТИС (а, скажем, SendMail, MS SQL и Apache), код, написанный разработчиками, будет совершенно другим, но архитектура при этом вполне может быть сходной. Как, впрочем, и совсем другой, скажем, с использованием тиражируемого модуля, который устанавливается в офисах партнеров, - все определяется особенностями бизнес-задачи и условиями, для которых создается проект.


СИСТЕМА ОБРАБОТКИ ЗАЯВОК КОМПАНИИ ОТИС

Российское представительство компании ОТИС - поставщика лифтов, эскалаторов, движущихся дорожек и т. д. - имеет центральный офис в Москве и сеть региональных филиалов в самых разных городах России и СНГ. Все филиалы присылают в центр заявки установленной формы на поставку продуктов и услуг. Здесь они обрабатываются и регистрируются; на основании указанной в заявке контрактной и адресной информации клиента центр присваивает контракту уникальный номер, который сообщается сотруднику, разместившему заявку, для дальнейшего использования. До недавнего времени все эти операции выполнялись вручную, но по мере роста числа заявок стали накапливаться нежелательные эффекты. Как видим, ситуация очень похожа на описанную в нашей условной задаче. Есть и еще одна общая черта: некоторые филиалы не имеют выделенного канала и пользуются соединением по коммутируемой линии, а значит, могут передавать свои заявки только по электронной почте — ввод в интерактивном режиме на Web-странице компании исключается.

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

Архитектурно система состоит из двух частей - клиентской и серверной. Клиентская часть отвечает за формирование заявки, передачу ее в серверную часть и получение номера контракта. Она может работать как в интерактивном режиме - через Web-интерфейс, - так и автономно, с отправкой заявок по электронной почте. Почтовый интерфейс представляет собой приложение на Visual Basic, использующее почтовый профиль для работы с MS Exchange Server, Web-интерфейс реализован на базе стандартного браузера. Функции серверной части - прием заявки, проверка ее корректности, сохранение информации из нее в базе данных Oracle, генерация номера контракта и отправка этого номера автору заявки. Их выполняет серверный агент, обеспечивающий взаимодействие между базой данных Oracle и - в зависимости от режима работы - почтовым сервером MS Exchange или Интернет-сервером на базе MS US, а также сами Oracle, Exchange и IIS.

Центральный федеральный округ