ТРЕУГОЛЬНЫЙ СТОЛ
Продолжение. Начало см. PC Week/RE, № /2002, с. 29; № /2002, с. 30.
Эта публикация завершает рассказ о технологических особенностях систем-конструкторов в разрезе их потребительских свойств. Авторы старались выделить общие черты рассматриваемых программных продуктов, помогающие, как говорят маркетологи, “отстроить их от конкурентов”. Кроме того, мы постарались особо подчеркнуть некоторые труднореализуемые технологические возможности, чтобы при покупке таких систем покупатель проявлял бдительность и “не клал уши на асфальт”.
Поскольку публикации материалов “треугольного стола” будут продолжены еще в нескольких номерах, мы приглашаем читателей тоже включиться в обсуждение - оперативно задать вопросы или высказать свои комментарии и замечания.
Пишите по адресу: monah@pcweek.ru.
Елена Монахова
Наталья Никитина, Юлия Гараева, Юрий Юдкин
Потребительское свойство № 4. Возможность изменения системы при помощи простых (в том числе визуальных) средств собственными силами потребителя для адаптации к специфическим и уникальным задачам управления.
Из дискуссии: “Что нравится потребителям в подобных системах? Что у него система под контролем. Он открывает в конфигураторе типовую конфигурацию, осмотрит, как она устроена: она для него открыта и прозрачна, он может понять, как эта система работает, что у нее внутри, какие “колесики” там крутятся. И для многих это важно. Там виден код, видны объекты метаданных, видны справочники... Каждый видит там все свое, и он спокоен. Самое главное, что система под контролем”.
Поговорим об инструментарии конструкторов, реализующем это свойство. Требования к нему прямо противоположны тем, которые предъявлялись к инструментарию, позволяющему вносить изменения в ядро: инструментарий должен быть достаточно простым, чтобы изменения мог осуществлять пользователь с низким уровнем подготовки в области программирования, но в то же время иметь богатые возможности для реализации сложных алгоритмов обработки данных. Здесь все разработчики единодушны: инструментарий должен быть многоуровневым.
Алексей Харитонов
Алексей Харитонов, руководитель отдела продвижения экономических программ “1С”: "... Чем отличается "конструирование" от программирования? Границы на самом деле нет, в каждой современной системе разработки сейчас содержатся и визуальные средства, и алгоритмические. В любой прикладной задаче есть участки, которые удобнее настраивать визуально (такие как структуры данных, формы ввода информации, печатные формы), и те, которые удобнее описывать алгоритмом. Например, формулы расчета налогов, конечно, удобнее описывать алгоритмически.
Мы стараемся предоставить разработчику прикладных решений возможности визуального проектирования основных структур данных и всего, что касается, например, интерфейсной части. Одно из упрощений для разработчика по сравнению с программированием на классических языках в том, что мы реализуем в готовых объектах технологической платформы порядка 80% функциональности учетных задач. При этом мы заведомо ограничиваем разработчика в каких-то возможностях, но в результате ему остается написать только тот код, который отвечает за специфику конкретной задачи - формулы расчета налогов, сумм бухгалтерских проводок и т.п. Он не должен думать например о программировании "машины проводок", об управлении экраном, технологических сложностях доступа к базе данных и т.д.
Простейшее внесение изменений в базовую конфигурацию осуществляется заданием значений соответствующих констант. Если необходимо правильно задать значения совокупности взаимосвязанных констант, то используются Визарды (Мастера, Эксперты): диалоговые окна, в которых пользователь поэтапно отвечает на вопросы, а по результатам ответов на них вносятся соответствующие изменения.
Для задания таблиц и запросов базы данных используются специальные визуальные построители и CASE-средства. Простейшие формы, отчеты и документы также строятся визуально. А уж если необходимо реализовать сложный алгоритм обработки документа или процедуру реакции на нажатие определенной кнопки, то тут на помощь приходят достаточно развитые встроенные языки программирования. Единственное, чего не хватает всем системам, это диаграммной модельной техники, когда путем графического задания модели получается не просто структура таблиц (как в CASE-технологиях), но первое приближение всей конфигурации, и потом останется только уточнить ее. Это более высокий уровень интегрированных средств. Такие средства позволят создавать собственные конфигурации пользователям, хорошо разбирающимся в предметной области, но далеким от программирования. Они смогут собирать конфигурацию для своих задач, минуя этап передачи пожеланий ИТ-специалистам, выполняющим настройку системы.
Борис Бабань
Борис Бабань, директор фирмы “ТБ Софт”: “В системе “ТБ.Корпорация” разработана специальная модель - Технология Бизнес-процессов (ТБ), которая лежит в основе оперативного и управленческого учёта. И задачей внедрения является просто параметрическая настройка этой модели. Но практика показывает, что стопроцентно параметрической настройкой не удается обойтись, приходится что-то допрограммировать с помощью встроенных языков, визуальных средств и т. п. Тут важно, что все-таки гораздо больше половины задачи удается решить параметрической настройкой без привлечения программистов. За счет этого и сокращаются сроки настройки”.
Алексей Харитонов, “1С”: "+От системы, которая используется для автоматизации ФХД предприятия, ожидается не работа с базой данных, не отображение на экране каких-то элементов управления, а решение конкретных задач - расчёт налогов, финансовое планирование+
И второй момент, который очень важен: в гибких современных системах должно быть общее средство описания модели данных, модели объектов. Оно позволяет создать индустрию поддержки, потому что обученный человек, знающий этот инструмент, его базовые принципы, может достаточно быстро разобраться в системе. Для сравнения: если вам предоставят готовую систему в исходных кодах, написанную на классических языках программирования (даже полностью в открытом виде), разобраться в ней очень проблематично. В результате у вас есть все исходные коды, но нет настраиваемой системы, потому что специалистов по той модели, которую на самом деле использовали авторы, вы вряд ли найдёте.
Следовательно, существенно именно наличие единой стандартизованной технологической модели, позволяющей достаточно быстро готовить специалистов. К примеру, по дереву метаданных разработчик с годовалым опытом может буквально за час-два разобраться в основах идеологии конкретного прикладного решения".
Задача разработки такого рода инструментов - весьма сложная, но первые удачные попытки создания подобных средств в мире уже существуют (например, Rational Rose), правда, пока не в области систем-конструкторов.
Вопрос методологий проектирования, заложенных в системах-конструкторах, требует отдельного серьезного изучения, и в рамках нашего экспресс-исследования провести его было сложно. Возможно, мы вернемся к этому вопросу в последующих публикациях на данную тему.
О самом больном
Теперь о следующем желательном, но далеко не во всех конструкторах в полной мере реализованном качестве.
Потребительское свойство № 5. Возможность внесения типовых изменений в систему с сохранением свойств адаптируемости к специфическим и уникальным задачам управления.
Это требование основано на том, что потребители не хотят полностью отвечать за конечную систему, предпочитая, чтобы часть ответственности была переложена на плечи фирм-разработчиков. Как упоминалось выше, все организации уникальны. Но уникальность не отменяет типичности отдельных аспектов их деятельности, таких, как необходимость соблюдать законодательство в области учета, своевременно начислять зарплату сотрудникам, управлять движением финансовых средств и множество других общих задач. Для конечных пользователей будет неэкономично расходовать свои ресурсы на доработку ИС под задачи, одинаковые для всех.
Елена Дворникова
Елена Дворникова, руководитель отдела продвижения ИС фирмы “Цефей”: “При использовании базовой информационной модели увеличивается скорость проектирования ИС, т. е. стоимость создания индивидуального решения для предприятия, “подгонки данного костюмчика (базовой системы) под данного заказчика”. Реально где-то от 40 до 60% бизнес-функций сохраняется на предприятии любой формы собственности и любых сфер деятельности. Различия не так уж велики, и если доделывать только этот отличающийся слой (дельту), то время настройки и внедрения системы управления сокращается в разы”.
Получается, что задачу “кооперации” должна решать фирма-разработчик, поставляющая пользователям как первоначальную систему, так и ее новые версии.
Эта задача для конструкторов распадается на две: а) разработка типовых конфигураций (типовых отраслевых решений, решений для определенных аспектов бизнеса и т.п.); б) выпуск новых версий ядра и среды разработки.
Лев Тришанков
Лев Тришанков, исполнительный директор “Алеф Консалтинг & Софт”: “...Как обычно это происходит: поставщики выпускают типовое прикладное решение, партнеры-внедренцы на его основе создают собственное типовое прикладное решение и адаптируют его при внедрении у конечного пользователя. Предприятие после ухода внедренцев продолжает “шевелить” некоторую часть системы. Предприятия потому и выбирают конструкторы, чтобы иметь возможность независимо от поставщика поддерживать в своих ИС критически важные для своего бизнеса функции так, как им необходимо.
Однако речь идет не обо всей системе. Та часть, которую они хотят самостоятельно развивать, обычно составляет не более 20-40% от объема всего, что в ИС реализовано.
Кроме того, они, конечно, заинтересованы в получении обновленных версий, но при условии, что обновления будут нормально объединяться с их уникальными наработками и это не потребует больших трудозатрат. При этом надо обеспечить возможность внесения всех этих изменений без остановки системы (особенно если она поддерживает распределенные процессы реального времени).
Еще одной важной проблемой является разграничение ответственности. Если что-то не так работает - должно быть ясно, кто будет отвечать: разработчик, партнер или конечный пользователь.
Сложность решения этой задачи состоит в том, что никто заранее не знает, в какой части большой и сложной системы партнеры или конечные пользователи захотят “сорвать пломбу, поднять капот и подкрутить гайки”.
Мы в “Алефе” ищем решение в области создания стандартных интерфейсов взаимодействия отдельных участков системы с ее общей стандартной инфраструктурой. В идеале мы должны научиться “втыкать” эти участки в общую инфраструктуру, как платы в компьютер. Уже сегодня нам удается добиться хорошей совместимости между типовыми и индивидуальными участками ИС на основе соблюдения внутрисистемных стандартов”.
Регулярные обновления типовых прикладных решений (изменения в соответствии с законодательством и пр.), по словам представителей фирм-разработчиков, участвующих в дискуссии, поставляются для всех рассматриваемых систем. Краеугольным камнем здесь является автоматическое сравнение типовых моделей с моделями пользователя и их автоматическое обновление. В связи с этим возникает важный вопрос: как производить обновление версий?
Если ядро конструктора не может быть изменено пользователем, а разработчики выпустили новую версию ядра, совместимую с предыдущей, то все должно быть в порядке: старая версия ядра меняется на новую и конфигурация остается без изменений.
Если же хотя бы одно из этих условий не выполнено или же клиент хочет вместе с новой версией ядра использовать возможности новой базовой конфигурации, то тут возникают проблемы. Наиболее простой и радикальный способ - полностью удалить старую версию системы, заменив ее новой с базовой конфигурацией разработчика. Но когда изменения конфигурации, внесенные пользователем, значительны, такой способ обновления может оказаться очень дорогим: придется снова повторять все этапы настройки конфигурации под свои нужды. В общем случае задача автоматического обновления версий пока в информационных системах не решена и скорее всего в ближайшее время решена не будет. Для преодоления этого рубежа, вероятно, потребуются серьезные разработки в области искусственного интеллекта.
Однако отдельные интересные решения в этом направлении имеются уже сейчас.
Фирма “Цефей”, например, предлагает встроенный механизм унификации выполненных изменений и настроек, обеспечивающий автоматическую проверку непротиворечивости внесенных изменений. В “Тектоне” (“ИнтелГрупп”) можно организовать автоматическое обновление только тех модулей, которые пользователем не дорабатывались, а для тех, которые были изменены, предоставляется выбор: либо оставить свои наработки, либо взять новый вариант. В системе “Алеф” (“Алеф Консалтинг & Софт”) инфраструктура “стандартов” позволяет достраивать систему, не исключая возможности проводить обновления функциональных модулей, причем выборочно, постепенно.
Интересный вариант реализован в системе Navision Axapta: в ней конфигурация состоит из шестнадцати слоев, каждый из которых предназначен для внесения изменений представителями разных групп (разработчики, администраторы, конечные пользователи). При этом конфигурацию можно переносить как целиком, так и послойно. Это облегчает задачу обновления системы в том случае, когда вышележащие слои не вступают в противоречия с новым вариантом нижележащего слоя. Однако в общем случае требуется ручное переконфигурирование.
Технологическое резюме
Подводя итог, зафиксируем квинтэссенцию потребительских и технологических свойств систем-конструкторов, т. е. еще раз обозначим качества, выделяющие их среди ИС разных классов.
В первую очередь - это возможность относительно недорого получить работающую информационную систему, позволяющую на основе типовых конфигураций собственными силами непрерывно адаптировать ее к уникальным задачам управления своей компании при помощи несложного инструментария (и при этом разделяя ответственность за систему с ее разработчиками).
Кроме того, системы-конструкторы перспективны тем, что являются промежуточным звеном между системами класса полностью “сделай сам” и жесткими коробочными системами.
Вне сомнения, будущее - за системами-конструкторами, но более совершенными, чем представленные на рынке сегодня. И направление их развития лежит в области создания более выразительных и простых методологий проектирования, а также в области стандартизации (читай: переносимости из системы в систему) этих методологий и моделей, построенных на их основе.
(Продолжение следует)
