Отправляет email-рассылки с помощью сервиса Sendsay

Кубики для взрослых

  Все выпуски  

Кубики для взрослых


Информационный Канал Subscribe.Ru

Кубики для взрослых


Переосмысление

Здравствуйте, мои дорогие читатели. Наверняка уже все позабыли, о чем говорилось
в прошлом выпуске, так давно он вышел.
Напомню, что я старался подвести все к необходимости определения цели и следить
за её достижением. Тогда система, которая будет обеспечивать информацией, достаточной
для принятия управленческого решения и будет правильной и полезной информационной
системой.
Иногда надо остановиться  и перестать упорствовать, чтобы дать окружающему миру
откорректировать свои взгляды на мир в правильную сторону. Очень полезно при
этом посмотреть, что происходит в реальности и пообщаться с людьми, лучше как
раз с теми, кто принимает решения, дабы посмотреть на их проблемы. Говорю я это
совсем не для того чтобы было больше слов. Это действительно очень интересный
процесс. 
Мало сказать, что нужно определить цель, надо же понять как это определение будет
выглядеть в информационной системе. И в этот момент появляется задача, которая
отвечает на этот вопрос, вернее заставляет на него ответить. Ну разве не чудо?
Задача казалось бы классическая -  контроль затрат в соответствии с утвержденным
бюджетом. Задача как задача. Но есть интересные особенности. Хочется контролировать
не только денежную составляющую, но и натуральные показатели. Я, надеюсь, что
Вы понимаете, что от такой постановки до универсального механизма определения
цели – буквально один шаг. Действительно план, или бюджет – это по сути дела
и есть те цели, которые надо достигать к определенному времени, а исполнение
плана в текущем периоде, как раз та основа, по которой можно судить - достигаются
цели, или нет. 
Вторая часть задачи – это сам процесс, который связан с контролем заявки. Процесс
довольно показательный и  имеет несколько фаз. 
1.      Создание заявки
2.      Расценка
3.      Проверка по бюджету
4.      Получение со склада (или запуск процесса закупки и затем получение со склада
)

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

Другой пример, который я тоже хочу привести связан с тем, что мне наконец стали
доступны тексты российских стандартов, которые соответствуют требованиям HASSP
(ГОСТ Р 51705.1-2001Управление качеством пищевых продуктов) и OHSAS 18000 (ГОСТ
Р 12.0.006-2002 Общие требования к управлению охраной труда в организации). Должен
сказать, что работа с этими стандартами несколько изменила мой взгляд на «зону
охвата» системы управления.  Фактически, HASSP определяет как должны строится
производственные процессы, чтобы соответствовать требованиям по безопасности.
Контрольные точки процессов, в которых производится проверка и анализ показателей,
в любом случае должны документироваться. И, по идее, это должно происходить в
реальном времени, поскольку в зависимости от результатов в контрольной точке
производственный процесс может идти по-разному. Таким образом, становится понятно
как отразить производственные процессы в системе управления, не только в части
описания, но и в рабочем режиме. Что касается охраны безопасности труда, то здесь
все просто очень красиво раскладывается на те требования, которые предъявляет
ИСО 9001 это и наличие инструкций и контроль компетенции персонала, единственное
что надо добавить  - это аттестация рабочих мест.

Таким образом проанализировав четыре стандарта (все выше названные + ИСО 14001),
которые кажутся мне наиболее полезными я пришел к окончательному выводу о том
как «правильная» система управления должна выглядеть так:

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

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

Вот так жизнь мягко корректирует наши взгляды на проблему, если мы конечно позволяем
ей это делать.
Ведущий рассылки: Михаил М. Баранов
bami@murometz.spb.ru www.murometz.spb.ru Создаем свою информационную систему


http://subscribe.ru/
E-mail: ask@subscribe.ru
Отписаться
Убрать рекламу

В избранное