Главный вход>>Аналитические статьи >> Идеальное и реальное в развитии корпоративных информационных систем

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

Яков Фельдман

Введение в проблему

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

Процесс идет обычно по одному из следующих сценариев.

1. Покупается готовый программный продукт. Продукт дорог. Купить его может только крупное предприятие. Приспособить процесс к продукту можно лишь отчасти. В конечном счете все равно приходится приспосабливать продукт к процессу.
   • Если предприятие очень богатое, оно платит разработчикам продукта и они доводят продукт под потребителя.
   • Если предприятие крупное но не очень богатое, оно пытается довести продукт своими силами и попадает в вариант (2)
2. Система разрабатывается и поддерживается своими силами. Вариант, реально существующий в жизни средних предприятий. Частные задачи существуют сами по себе. Чем больше задач и чем шире они реально используются, тем хуже качество информации в целом.
   
   Первая причина - децентрализация ввода данных. Если раньше (В эпоху mainframe) за качество вводимой информации отвечали специалисты, то теперь любой инженер (конструктор, технолог, экономист) вводит те данные которыми владеет.
   
   Вторая причина - децентрализованная разработка программ и структур данных во обеспечение этих программ. При централизованном вводе данных все пользователи - под контролем. При децентрализованном - каждый пользователь может ставить задачу "своему" программисту. Так на едином информационном пространстве возникает хаос задач и испоьзуемых ими данных.
   
   Эти причины усиливают друг друга - если в структурах заложен ввод одного и того же документа дважды, то высока вероятность, что один раз его введут с ошибкой и два противоречащих друг другу документа будут существовать в системе на равных. И наоборот. Противоречия в информации блокируют возможность совершенствования структур в процессе работы. Представьте себе, что мы обнаружили необходимость двойного ввода до наполнения базы. Здесь эту ошибку легко исправить. А если у нас в системе уже существуют пары равноправных противоречащих друг другу информационных образов одного и того же реального документа? Тогда, если мы хотим оставить только один образ из двух, по каждой такой паре надо принять отдельное решение. В реальной жизни число таких необходимых решений столь велико, что никто дажет не ставит подобных проблем и ошибка проектирования становится вечной.
3. Для мелких предприятий наиболее вероятным является использование локальных приложений в среде типа Microsoft Office. Но если на этом предприятии оказываются люди понимающие в программировании, то они хотели бы разработать интегрированную информационную систему. Иногда они даже начинают такие разработки, но большая трудоемкость процесса не дает им далеко продвинуться.

Предлагаемая нами технология (Условное название D2C3) значительно понижает стоимость разработки и поддержки интегрированных информационных систем при высоком качестве проектных решений по структурам данных и очень высоком качестве информационного наполнения этих структур. Чем достигается такой результат?

Как решать проблему

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

1. Персональная ответственность каждого пользователя за вводимую им информацию.
2. Персональная ответственность одного эксперта за все структуры данных.

и двух малых принципов

1. Отделенность системы поддержки данных от системы презентации
2. Автоматическая настройка системы поддержки данных

Разумеется для практического исполнения этих принципов необходима программная поддержка. Средства такой поддержки уже разработаны и находятся в процессе тестирования.

ПОСЛЕСЛОВИЕ

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

Автономная ИТ-среда и бизнес-процессы

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

Однако попытка прямо продать эту технологию обречена на неудачу.

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

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

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

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

Технология FTS

1 - База данных, объекты и пользователи, документы и запросы.
2 - Бизнес-процессы, модели, персонажи, функции, условно-конкретные критические сценарии, старые и новые.
3 - Демонстрации и презентации
4 - Тесты

Центром разработки является Блок 2.

Один из вариантов - записать его на языке Java.
Модель (тип предприятия: завод, университет, госпиталь) это Java-package.
Персонаж (тип человека: сотрудник, администратор, посетитель) это Java-class.
Функция (тип действия: обслужить покупателя, получить товар, провести семинар) - это Java-function.
Системные объекты (документы, деньги, единицы товара) это классы системного Java-package.
Системные функции (послать документ, заплатить деньги) - это функции системного класса Person от которого унаследованы классы всех персонажей.
В каждом пакете есть свой класс для демонстрации. В этом классе есть несколько статических функций - сценариев.
Прокрутка сценариев порождает поток сообщений. Этот поток используется для отладки сценариев.

Когда блок 2 завершен, по нему строятся блоки 1, 3 и 4. В идеале они строятся автоматически для определенной среды.

Блок 3 должен удовлетворять следующим критериям восприятия

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

Сценарии в блоке 2 должны быть построены так, чтобы при порождении блока 3 выйти на эти 4 критерия.
Соответственно подбираются демонстрируемые ситуации, персонажи, функции.

Для того, чтобы блоки 1,3,4 выполнить ассинхронно после готовности блока 2, необходимы промежуточные (21, 23, 24) скрипты. Нужно принять соглашения, позволяющие блоку 2 информацию записать в последовательный файл, а блокам 1,3,4 эту информацию считать и выполнить шаг за шагом.

Блок 1 получает

1. описание типов документов.
2. описание типов пользователей
3. запросы к базе

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

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

Блок 3 получает команды для исполнителя презентаций.

Второй вариант - сформировать блок 2 из специального редактора скриптов. Внутри этого редактора возможно редактировать данные блока 2, отлаживать их, формировать цепочки для блоков 1, 3, 4. Из этого же редактора их можно править и выполнять.

Третий вариант - записать блок 2 на простом XML

Что такое "новая методология"

Инновационный процесс разделим на этапы

1. Идея
2. Методология
3. Технология
4. Продукт

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

Я предлагаю новую методологию создания и использования информационных систем. Чтобы увидеть новизну и преимущества этой методологии (условное название - FTS) надо сравнить ее с другими методологиями. Но по какому основанию мы будем их сравнивать?

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

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

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

Предлагаемая технология FTS состоит из двух частей (F-помечено оранжевым и T-помечено красным. F - готово как технология, Т - как технология - в работе).

FTS предполагает (1) описание сценариев на стандартном XML. После чего (2) генерируются презентации, тесты и типы данных. (3) После ручной корректировки типов создаются структуры базы данных. (4) Формы поддержки генерируются в процессе работы (динамически). (5) Отчеты пишутся полуавтоматически. (6) Расширение технологии происходит редко.

Ближайшая задача по продукту - MLM (Multi-level-marketing) как учебная модель. Ближайшая задача по технологии - три генератора, преобразующие набор сценариев в (1)презентацию, (2)структуры данных и (3) тестовые цепочки. В работе также два тест-клиента. Первый тестирует все линки, доступные клиенту, на выполнимость. Второй выполняет тестовые цепочки после генератора тестов.

Аналоги и конкуренты

Среди российских софт-производителей никто не разрабатывает систем, начинающих работу с анализа и оптимизации бизнес процессов.

Среди зарубежных софт-производителей этим занимается например Cognos. Продажи этой компании выросли запоследний год на 25% (по данным cnews.ru) что говорит об общей перспективности направления. Однако на российском рынке зарубежные компании такого типа не могут конкурировать с российскими. Во первых по цене продукта. Во вторых, по набору готовых бизнес-моделей, сделанных на западном (а не российском) материале. И, в третьих, по необходимсти плотного сопровождения, когда совершенствование бизнес-модели происходит мелкими толчками и только при наличии тесного контакта разработчика и клиента. Соответственно клиент платит мелкими порциями, что является для него единственным психологически приемлемым вариантом.

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

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

 

Авторы

Темы, проблемы, понятия, концепции

Течения, движения, идеологии

Аналитические статьи

Страны, эпохи

Другие сайты

©Y.Feldman