Пост на помидорку: Лаборатория орг.администрирования, de re и другие сложные мысли

В субботу прошла первая встреча лаборатории. Полноценно участвовать я не смогла - в пути задержались больше, чем было заложено запасного времени, и в выбранный отель не заселили, и нормальный канал не смог обеспечить ни один из трех операторов (SLTMobitel, Dialog, Airtel). Но слушать я могла. И то что слышала - попробую сделать.

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

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

На встрече говорили о том, что практики администрирования, аналогичны практикам разработки, только использоваться будут в другом кусочке мира и по другому будут называться.

Теперь я попробую выписать черновик этих практик:

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

Разворачивают администрацию и оперируют практиками менеджмента.

Проверить попробую на договорах:

  1. Все действия которые мне нужны при подготовке договора, происходят на каком то его состоянии, возьмем модель состояний договора
  2. На каждом из состояний есть какие то действия по правилам, включая проверки (из состояния «Протокол закупочной комиссии» в «Заявка на закупку» перейти просто так например не можем, можем перейти в состояние, например «Договор с закупочными процедурами»)
  3. Строим таблички для учета состояний и их отслеживаем, выполняя действия для состояний (где можно - автоматически)
  4. Договариваемся про логистику и включаем договоренности в действия для состояний
  5. Настраиваем проверки и их тоже, включаем в действия для состояний с учетом логистики (кому должно прийти по результатам проверки)

Дальше отслеживаем п.3 по скорости и точности и если надо правим. И если новый договор - правим, в отличающихся местах.

На правах материалов для подготовки к совещанию я читала о моделях в перспективах de se (кажется это то что Анатолий называет СебеУчет) и de re (ТебеУчет). Это было тяжелое чтение. Конструкции из не каждый день встречающихся слов, в голове расшифровывались в хоть какие то смыслы, сильно не с первого раза. Но кое-что прочесть удалось:

  • Проблему учетных систем, с внутрихозяйственными операциями, которые из большинства отчетов исключаются - я видела 150000 раз (как человек из отрасли 1С). О том что эта проблема решаться может, только нужны другие правила учета, задумалась первый раз
  • Долго рассматривала картинки в примере с банками, где были схемой представлены данные о межбанковских переводах, в какой то системе. И та система может выполнять верные действия, только после указания ей роли (система в примере может быть администратором и делать одни действия при переводе или владельцем счета и делать другие действия). Следом шел второй набор схем, о ТебеУчете, где текстом описывается упрощение и еще раз упрощение, от того что в системе учета роль «прибивается гвоздями сразу» и показаны более сложные, схемы с данными о тех же межбанковских переводах
  • Agent-neutral (агентно нейтральные) системы можно использовать для разных ролей, без изменения в системах, а не только для разных экземпляров одной роли как в случае с agent-relative (агентно относительными) системами.

Еще, читала и говорили о проблемах регистрации перехода права. Есть такие состояния у учитываемых объектов «в пути». И для точного учета нужно перед передачей объекта от владельца к владельцу, регистрировать состояние «объект в пути». Тут думала о том что с учетом автоматизации регистрировать это состоянии будет иногда дольше, чем не регистрировать. Cложно)

*помидорок ушло 6

**Модель Kandinsky 2.1 нарисовала: учет договоров на складах в стиле pencil_drawing