Итак …
с последней заметки прошло уже 19 дней.
за этот период произошли вещи.
сегодня в рамках работы над проектом сквозной автоматизации командировок обновил fpf на свежую версию.
точнее было так: сначала долго не мог попасть в гигачат. это было настолько долго что даже пришлось писать письмо в поддержку что не могу ни войти ни пароль сбросить. через час смог зайти в аккаунт. но это уже было под конец рабочего дня. соответственно, успел только создать артефакт который описывает все документы которые возникают в командировке и против каждого документа поставить информационную систему в которой эти документы возникают.
такой разрез необходим чтобы увидеть все доступные альтернативы вариантов сквозной автоматизации и потом рационально выбрать тот вариант который нам будет удобнее с учетом того что такое решение должно работать неограниченно долго в любых разумных условиях. (это отсылка к идеям заложенным в языке lisp и редакторе emacs, который продолжает развиваться с 80-х годов, или к идеям Джона Кармака про разработку Doom)
докинул пару новых идей которые мне пришли в голову ранее. обновил части моделей.
после этого вспомнил, что fpf тоже обновился. перезалил его в ИИ. запросил еще раз пересмотреть модель, обновить артефакты, выпустить протокол работы за день. артефакты выгрузил. завтра прочитаю, вникну, осмыслю.
в целом по этому проекту есть замедление так как я еще нахожусь в состоянии сбора данных с пользователей-участников процесса. экономисты свою часть уже рассказали, сейчас очередь бухгалтерии. они дают очень развернутые описания как это есть сейчас.
но в любом случае основное внимание сейчас приковано к запуску нового сэда.
в проекте по сэд я работал с весны до конца лета, когда уже моя активность стала снижаться. я в одно лицо разгонял проект и налаживал рабочий процесс между подрядчиком и представителями бизнеса и инфраструктуры с нашей стороны. чтобы процесс обследования и начался и подрядчик имел возможность собирать необходимые исходные данные для настройки системы. инфраструктура понимала какие ресурсы необходимо выделить под проект. чтобы договорники заключили правильные договоры и у всех на руках были необходимые документы и соглашения.
далее чтобы у подрядчиков были все необходимые доступы и входы-выходы в инфраструктуру.
на этом этапе я на базе qwen (бесплатной) запили системную схему проекта и собрал набор альф, карточек ролей, матриц, гейтов и связей между ними + журналы изменений. на такой схеме я ехал почти весь проект до запуска и на нем обкатывал навыки работы с таким артефактами и ежедневными ритуалами по 15 минут.
работать в этой схеме приходилось самостоятельно за все основные роли, так как такая схема работы не официальная и было бы не реально заставить всех участников проекта (даже проекта официально не было запущено с определением ролей и участников) работать по такой схеме. с другой стороны я почти полностью контролировал ситуацию и занимался оркестрацией коллег в рамках этого проекта. уже на последнем участке где надо было крутить гайки серверам, возиться с сквозными авторизациями и грузить оргструктуры я немного отошел в сторону. ну как отошел … меня бросили разгребать другие проекты которые замутили коллеги из блока hr.
по сэду вскрылись интересные особенности которые мы не видели на этапе внедрения. тк у нас внутри компания живет по 2м структурам: кадровая органиграмма и управленческая структура (центры финансовой ответственности), это привело к тому, что на этапе подготовки подрядчик считал, что нам должно хватить кадрового разбиения (ну на самом деле он даже не думал в сторону управленческого разбиения) и когда запустились, то оказалось, что на уровне топ менеджеров они могут в рамках кадрового разбиения числиться в одной организации а управлять через управленческую структуру людьми в другой организации, в которой они вообще не числятся. естественно сэд про это ничего не знал и не мог корректно вычислить подчиненных у таких руководителей в других компаниях. пошел подрядчик чинить и придумывать костыли.
блок hr.
тут целый куст проектов: подбор, кэдо и командировки (выше уже писал).
по кэдо коллеги наконец услышали про что я им рассказывал от имени иб. что тот код, тот плагин который они хотят предлагают нам установить в нашу систему в закрытом контуре должен быть сертифицирован компетентными организациями, так как даже если мы сами посмотрим открытые исходники мы не в праве говорить что код безопасен и не понижает наш уровень защищенности. аргумент подрядчика что “наш код установлен в облаке 1c фреш” для нас ничего не доказывает и ничего не объясняет. указал ему что вообще разговаривать на эту тему надо с иб и владельцем системы одновременно и запросил у него встречу с инженерным составом с их стороны совместно с нашими специалистами чтобы обсудить особенности соединения 2х герметичных контуров. больше недели думали и предварительно согласились собраться на уже этой неделе в конце.
я забил встречу в календаре. с нашей стороны количество участников от бизнеса каждый день прибавляется (по ходу им просто интересно что там за такая тема с безопасностью, вокруг которой столько возни). посмотрим что из этого выйдет. вместе с этим подрядчик закинул вопрос о том, какая компания может сертифицировать код плагина (какая нас устроит), чтобы мы смогли принять ее документы как доказательство безопасности кода.
мой интерес во всей этой суете такой: чтобы все ролевые интересы были учтены в этом проекте и никто не ушел необилеченным. у меня получается развернуть проекты вспять и поставить их на корректную траекторию, чтобы в конце мы не уперлись во все те же вопросы информационной безопасности. лучше мы сейчас их урегулируем. ведь изначально представители бизнеса считали что достаточно только заключить контракт с поставщиком и согласовать с иб что внешний сервис расположен в сертифицированном облаке. на что иб конечно же не возражало. а тот момент что есть еще история с соединением с этим облаком через шифрованный канал с установкой плагина в учетную кадровую систему не проговаривался и не обсуждался. я это поправил. и вот мы уже готовится к встрече.
параллельно с этим помог кадрам с разработкой приказа на проект внедрения кэдо. написал им сырой черновик какие роли за какой участок должны отвечать. сегодня прилетел уже красивый проект приказа, где местами прям копипасты из моего черновика (я как-то даже не рассчитывал что они в таком виде переедут 
). цель была просто чтобы не забыли никого по пути важного в этом проекте. но тем не менее обсуждение ведется. предлагаются варианты улучшений. процесс идет.
почему это важно (для меня, по крайней мере) - обычно иб на предприятиях не любят (это те люди которые постоянно требуют смену паролей, не разрешают флешки и ходить на пикабу с рабочего пк 
). и либо их забывают добавить в проект, или стараются не привлекать. тут я намеренно начал топить за то что без этих людей проект не взлетит и бизнес стал проникаться.
у подбора с облачной crm такие же нюансы с иб, которые они пока до конца не осознали, но мы двигаемся к пониманию проблематики. коллегам нужно дать немного времени чтобы они привыкли к терминологии и приняли сложность мира и сложность связывания герметичных инфраструктур.
дальше будем следить за развитием событий.
ну и в фоне еще допиливаю модель которая рассчитывает количество необходимого персонала в отделе. проверяю модель и осмысливаю ее, чтобы понимать что она выдает. но тут все сильно вяло, тк пока мы не запустим сэд никто этой моделью заниматься не будет. ну и в любом случае, есть высокая вероятность того, что какой бы результат модель не выдала, все равно ставок выдадут столько сколько будет средств в бюджете. так что эта модель - это больше для себя для души, посмотреть, что можно делать с помощью ии)
вроде все что было из интересного рассказал. nda вроде нигде не нарушил, ничего не разгласил)
такие дела.
спасибо за внимание.