Кадровая политика

Основные стадии консультационного процесса

News image

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

Ошибки руководителей

News image

Система управления и управленческая структура в России до сих пор находятся в плену прошлых стереотипов, и очень часто дире...

Что же предлагали первые консультанты, которые появились в 20-х годах?

News image

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

Авторизация



Особенности систем, ориентированных на знания

Кадровая политика - Управление знаниями

особенности систем, ориентированных на знания

В публикациях, анализирующих преимущества и недостатки технологий разработки программных систем, из года в год повторяются истины, набившие оскомину с начала 80-х гг . Однако, менталитет потребителя КИС управления мало изменился за эти годы и даже деградировал. Последнее связано в первую очередь с ориентацией экономических вузов на подготовку для организаций управленческого звена «интуитивного», а не аналитического склада [9, 10]. С учетом данного обстоятельства, а также предложения систем класса Knowledge Management (КМ) и других факторов, вносящих дополнительную неразбериху в базовые понятия, является настоятельно необходимым эти истины повторять.

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

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

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

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

При такой формализации бизнес – логики возникают дополнительные удобства для пользователей и разработчиков АСУ БП: (1) пользователи более оперативно могут реагировать на флуктуации рынка и изменения нормативной базы; (2) разработчики могут легко локализовать и модифицировать правила, когда необходимы изменения политики без необходимости компиляции кода.

Такой гибкий подход контрастирует с общей практикой разработки АСУ БП, которая представляет БП в виде программных объектов, подобных COM, JavaBeans, прикладным классам или запросам к базам данных.

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

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

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

Объектно-ориентированное проектирование бессильно помочь, когда пользователь желает изменить бизнес – логику. Для ее изменения объектно-ориентированная АСУ БП потребует неадекватно большого времени. Смешение правил и объектов рассеивает логику по приложениям, затрудняя ее локализацию и увеличивая затраты на реакцию на изменения рынка.

Говоря о проблемах объектно-ориентированного подхода, мы пространно и нечетко выражаем ясную мысль С.П. Никанорова о системе конструктов [3], или о проблеме отсутствия общей для разработчика, пользователя и внешней среды концепции, на основе которой можно было бы разработать «гибкую» АСУ БП, дружественную к изменениям, происходящим в организации и вне ее.

Помощь разработчика становится ненужной, когда АСУ БП, ориентированное на знания, использует для описания правил управления язык, похожий на естественный. Синтаксис представления правил, близкий к речевому и являющийся универсальным конструктом, обеспечивает отсутствие ограничений на внесение изменений в базу правил непрограммистом.

Когда организация ищет новые пути разработки и внедрения приложений, автоматизирующих деятельность, возникает особый интерес к гибкости и оперативности АСУ БП, ориентированных на знания. Такие АСУ БП особенно необходимы там, где: (1) пользователи нуждаются в быстрых и нетрудоемких изменениях декларативных организационных знаний; (2) приложения управляются событиями и должны реагировать на комбинации событий; (3) причинно-следственные связи БП сложны и пока до конца не исследованы или не описаны; (4) не существует алгоритмических (математических) алгоритмов решения проблемы.

Для разных отраслей могут выполняться одно или несколько из перечисленных условий. Независимо от того выпускает ли компания строительные материалы, использует ли электронные или обычные каналы сбыта, могут быть разработаны правила для управления транзакциями, оценки сценариев и принятия решений. Сегодня наиболее известным и мощным пакетом, используемым для разработки АСУ БП на основе знаний, является продукт компании ILOG. Приложения ILOG активно используются сейчас в ERP-системах, а пакет оптимизации ILOG де-факто стал стандартом для таких разработчиков ERP - систем, как Adonix, Baan, i2 Technologies, J.D. Edwards, Oracle, PeopleSoft и SAP.

Успех ILOG на рынке свидетельствует не только о перспективности технологий, основанных на управлении знаниями и осознании разработчиками элементов ERP систем этого факта, но и о некоторой неповоротливости их генеральных конструкторов, нерешающихся на признание технологии управления знаниями в качестве базовой для разработки ERP-систем в целом. Здесь нельзя не отметить революционной заслуги отечественной компании Эллай, разработавшей КИС «Ресурс» целиком на технологиях управления знаниями, но не нашедшей пока широкого признания.




Читайте:


Добавить комментарий


Защитный код
Обновить

Менеджмент знаний:

Основная проблема управления знаниями и ее решение

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

Особенности знаний. Переход от Базы Данных к Базе Знаний

Особенности знаний: Внутренняя интерпретируемость. Каждая информационная единица должна иметь уникальное имя, по которому ИС находит ее, а также отвечает на зап...