Самообучающиеся организации, Процессная эффективность | Олег Брагинский, Максим Мухтаров
Основатель «Школы траблшутеров» Олег Брагинский и ученик Максим Мухтаров рассказывают о том, как организовать процесс наполнения базы знаний технико-аналитического подразделения в отечественных многопрофильных медицинских учреждениях.
Крупная частная медицинская сеть вывела внутренних разработчиков в отдельное юридическое лицо. Элементом материально-технического обеспечения стала покупка решения для базы знаний. Получив доступ, организационные подразделения принялись заполнять выделенное пространство.
Централизованно сообщили правила информационной безопасности, остальное начальникам предстояло определить самостоятельно. В Управлении по работе с данными решили продумать: а) структуру статей, б) способ внедрения взаимодействия с системой в повседневную практику.
Политика в области конфиденциальности резюмировалась указанием: «запрещено выкладывать чувствительные данные». Дополнительно учтя опыт смены вендоров и on-premises-приложений на cloud, постановили, что вместо загрузки файлов в базу, будем указывать пути к сетевым папкам.
Статьи структурировали в виде иерархического дерева по двум критериям: а) относимость к процессу – административный или производственный; б) непосредственность объекта описания – собственно последовательность операций или обеспечение, применимое для многих видов работ.
Административные процессы проистекали из зоны ответственности руководителя подразделения, которую можно было опубличить. Раскрывать контроль за подчинёнными нельзя – теряется управляемость; также недопустимо делегировать «бумагам» стратегию и получение ресурсов.
Создали разделы под онбординг и офбординг. Первый описывал организацию рабочего места для нового сотрудника: получение доступов и установку программ. Второй включал чек-лист при увольнении: предупредить заказчиков, переназначить задачи, сохранить файлы в личный архив.
К обеспечению административных процессов отнесли совместные ресурсы: URL’ы веб-приложений, чаты, трекинговые доски, репозитории GitLab, базу знаний, общий почтовый ящик, сетевые директории. Описали состав команды, встречи в календаре, выделенное оборудование.
Производственные процессы заключались в создании функциональных продуктов:
- разработчики развивали приложение по управлению маркетинговыми рассылками
- техническая поддержка обрабатывала заявки и обслуживала системы
- специалисты по работе с данными проводили ad hoc исследования
- BI-аналитики автоматизировали обновление отчётности.
Регламенты описывали необходимые ресурсы, этапность, собственный стандарт кодирования: стандартизацию работы линейных сотрудников считали важнее описания архитектуры, нужной только техлидам. Документация в базе знаний создавалась побочно – в ходе выполнения задач.
Обеспечение создания функциональных продуктов делилось на две группы: а) инфраструктура – описание физического размещения архитектурных компонент разрабатываемых систем; б) инструменты – инструкции к программному обеспечению, необходимые для конкретных работ.
Инфраструктуру формировали перечни виртуальных машин. В таблицах указывали имя сервера, IP-адрес, принадлежность к приложению и контуру, предназначение, операционную систему, установленное ПО, оперативную память, объём и тип жёстких дисков в разбивке, количество CPU.
Списки технических учётных записей для доступа на серверы и используемые в самих системах хранили в файлах под паролями на защищённых сетевых директориях. В базе знаний упоминали только пути. При авторизации через Active Directory писали группы, в которых необходимо состоять.
Инструменты включали: а) десктопное и консольное ПО; б) корпоративные приложения; в) языки программирования. Первые покрыли инструкциями по настройке и основным командам. Для вторых описали нюансы работы с GUI. По третьим перечислили вызовы функций и отдельные конструкции.
В качестве интегрированных сред разработки устанавливали PyCharm и Visual Studio, для запросов к базам данных применяли SQL Server Management Studio и DBeaver. Фиксировали часто используемые встроенные команды в Windows cmd и Linux CLI. Описали основные инструкции git.
Среди корпоративных систем и веб-приложений выделили Медиалог и Инфоклинику – электронные медицинские карты, Microsoft Dynamics CRM – работа с жалобами и программа лояльности, Axios Assyst – обработка заявок, GitLab – контроль версий кода, Яндекс Трекер – постановка задач.
Для языка python описали вызовы через командную строку функций применяемых фреймворков и библиотек: django, pytest, alembic, pip. В отношении SQL раскрыли разбиение массовых INSERT, UPDATE, DELETE на пачки в циклах, рекурсивные CTE, свёртку строк в одну, работу с XML и JSON.
Плановое редактирование возникало в трёх ситуациях: а) появлялась новая деятельность или инструмент; б) специально ставили задачу обновить описание под проектируемую оптимизацию процесса; в) регламент выполнения проектных работ включал шаг с созданием документации.
Ad hoc изменения вносили в двух случаях: а) сотрудник сталкивался с проблемой, которую не мог решить самостоятельно – не прибегая к поиску в интернете или обращению к коллегам; б) на встречах в режиме демонстрации экрана подмечали у товарища «фишку», достойную упоминания.
Знания распространяли двумя путями: а) в порядке делегирования новой для сотрудника задачи – при выполнении приходилось искать соответствующую статью; б) информированием на еженедельной встрече подразделения – коллеги делились ссылками на обновлённые материалы.
Отдельно отметим ненадёжность и недружелюбность облаков. Руководитель обязан иметь актуальный дубликат в редактируемом десктопном формате у себя и на сетевых папках. Особо компетентные распечатывают регламенты в бумажном виде и размещают рядом с рабочим местом.
Когда фамилии звучат вместо должностей, собственникам стоит насторожиться: зависим от «уникального» специалиста. Боясь увольнения, сотрудники зажимают информацию – появляются завалы на определённых участках. Возникает навязчивое желание избавиться от узкого горлышка.
Начальникам следует указать подчинённым путь к безопасности, сменяя антагонистический конфликт на общую цель: жертвовать «персональный мозг» в «организационный бульон» – значит повышать вероятность карьерного роста, высвобождая время. Учить других – лучшее развитие.