(Окончание, начало см. https://rusrim.blogspot.com/2025/07/1_01147231579.html )
Архитектура приложений в рамках облачных офисных пакетов
Организации обычно устанавливают разрешения на доступ и сроки хранения в качестве значений по умолчанию для агрегаций/контейнеров (папок, сайтов, учётных записей и т.д.). Такой подход обычно более эффективен, масштабируем, безопасен и является более простым для мониторинга, чем установление этих правил непосредственно для отдельных объектов (хотя возможность устанавливать исключения из значений по умолчанию также важна). С точки зрения управления документами, ключевыми элементами архитектуры любой системы являются агрегации, для которых по умолчанию могут быть установлены разрешения на доступ и правила хранения.
Архитектура, заложенная в основу корпоративного приложения для совместной работы / управления документами, оказывает решающее влияние на:
- Скорость развёртывания приложения;
- Спектр организаций, способных развернуть это приложение,
- Точность, с которой правила доступа и сроки хранения по умолчанию могут быть установлены для контента, созданного или полученного в приложении.
Здесь существует определённый компромисс. Для любой корпоративной системы управления контентом/поддержки коллективной работы:
- Формирование архитектуры, на основе которой контент объединяется в специфические для деловой деятельности агрегации (например, папки для конкретных проектов, дел или вопросов), потребует относительно много времени и относительно высокого уровня зрелости управления информацией, - но такая архитектура будет поддерживать относительно высокий уровень точности при назначении правил доступа и сроков хранения по умолчанию.
- Архитектура, в рамках которой контент агрегируется в сайты / диски / учётные записи групп пользователей или отдельных лиц, потребует относительно короткого времени для развёртывания, и может быть развёрнута организациями независимо от уровня зрелости в плане управления информацией, - но она будет обеспечивать меньшую точность при назначении правил доступа и сроков хранения по умолчанию.
У организаций, как правило, имеются списки всех их сотрудников и перечни всех структурных подразделений. Это делает относительно простым процессом развертывание системы, в которой сайты, диски и учётные записи выделяются отдельным лицам или структурным подразделениям. В то же время у организаций, как правило, не имеется перечней всех видов работ, выполняемой во всех областях их деловой деятельности. У них обычно не имеется даже перечня всех типов выполняемой работы. Это делает развёртывание корпоративной системы, основанной на функциях и видах деятельности, далеко не простым процессом, поскольку центральной группе внедрения приходится выявлять все эти виды работ (и конкретные работы данных видов) по мере развертывания системы.
В конце 1990-х и начале 2000-х годов различные государственные учреждения в различных юрисдикциях выпустили требования к системам электронного управления документами. Все эти требования основывались на предположении, что, как только цифровой мир устоится, организации захотят использовать архитектуру, основанную на функциях и видах деятельности.
Такие требования создали рынок для класса систем, ставших известными как системы управления электронными документами и контентом (electronic document and records management, EDRM). Это был нишевый рынок, поскольку только организации с сильными навыками управления документами и информацией могли развернуть системы этого класса. Это было связано с тем, что архитектура данных систем требовала наличия корпоративной схемы классификации видов деловой деятельности, - а такие схемы классификации непросто сформировать, протестировать и обеспечить согласие с ними внутри организации.
Рынок современных гипермасштабных облачных офисных пакетов принципиально отличается от локального рынка систем управления контентом и иных корпоративных систем 2000-х и начала 2010-х годов. Облачные офисные пакеты обслуживают гипермасштабируемый рынок, который охватывает «растягивается» до масштабов всей цифровой экономики и который не может поддерживать нишевые рынки. Соответственно, эти пакеты должны быть спроектированы таким образом, чтобы любая организация, большая или маленькая, могла их развернуть.
Фундаментальный сдвиг в способе агрегирования документов
Переход к облачным офисным пакетам привёл к сдвигу:
- в сторону архитектур, ориентированных на обслуживание групп и отдельных лиц, - в рамках которых группам предоставляются сайты, а отдельным лицам – учётные записи); и
- прочь от архитектур, основанных на функциях и видах деятельности, - когда у организации имеется своего рода иерархическая классификация её достаточно широких областей работы, а новые агрегации (сайты, библиотеки или папки) создаются в том случае, когда открываются новые виды работ / проекты, которым назначаются соответствующие места в иерархической структуре.
Данный сдвиг является неизбежным следствием перехода к гипермасштабам.
По сравнению с эквивалентными приложениями из эпохи локальных вычислений, приложения для поддержки коллективной работы / управления документами в Microsoft 365 и Google Workspace имеют более простую архитектуру, менее настраиваемы и, как следствие, могут быть развёрнуты быстрее. Сравните типичное время, необходимое для развертывания Microsoft Teams, где-то в 2020 году (измеряется в неделях) со временем локальной реализации SharePoint где-то в 2010 году или развёртывания локальной EDRM-системы где-то на рубеже 2007 года (измеряется в годах).
Действительно, Microsoft и Google могут предложить премиум-сервисы отдельным сегментам своего рынка - например, Microsoft может предложить дополнительные функциональные возможности для управления информацией клиентам, готовым купить лицензии E5 вместо лицензий E3. Однако премиум-функции управления информацией существуют в рамках отдельных сервисов администрирования (которые в случае Microsoft 365 идут под маркой Microsoft Purview). Приложения, развернутые для конечных пользователей (которые, в случае Microsoft 365, включают Teams, Outlook/Exchange и OneDrive), имеют базовую архитектуру, которая одинакова для всех клиентов, больших или малых, независимо от их лицензии.
Конечно же, архитектуры на основе функций и видов деятельности никуда не исчезли. Когда организация развертывает систему поддержки основной деловой деятельности для одного конкретного вида деятельности, она неизменно использует архитектуру, основанную на видах деятельности (вспомните системы управления запросами на обслуживание, системы кадрового учета, системы студенческой документации и т.д.). Однако для организации было бы экономически невыгодно развертывать специальные системы для каждого отдельного направления деловой деятельности. Экономическая эффективность достигается лишь в случае, когда для разработки специальных систем отбираются те направления деловой деятельности, с которыми связаны наибольшие объёмы контента или контент, имеющий наибольшую ценность. Все остальные виды деятельности будут, как правило, использовать многоцелевые корпоративные системы, и эта роль теперь обычно выполняют гипермасштабируемые облачные офисные пакеты.
Интуитивное представление о том, что мы можем устанавливать правила доступа и сроки хранения более точно, когда знаем особенности деловой деятельность, в рамках которой возник контент, по-прежнему справедливо. Это интуитивное представление может помочь диагностировать некоторые из проблем, с которыми организации столкнутся с течением времени при управлении (и использовании) контента в агрегациях на основе интересов групп и отдельных личностей. Оно также способно помочь с проработкой вариантов использования методов ИИ и аналитики данных в интересах повышения точности, с которой для контента устанавливаются права доступа и сроки хранения.
Тот факт, что в цифровой экономике конвергенция в корпоративных многоцелевых системах шла в сторону архитектур на основе интересов групп и отдельных лиц (а не функций и видов деятельности), не означает провала в управлении документами или в стратегическом управлении информацией. Это просто изменение контекста, в котором они работают. Конвергенция произошла вследствие того, что корпоративные многоцелевые системы теперь являются гипермасштабируемым сервисом. Архитектуры на основе функций и видов деятельности стали бы узким местом на пути превращения корпоративных многоцелевых систем в гипермасштабируемые сервисы.
Джеймс Лепен (James Lappin)
Источник: блог «Thinking Records» (Думая о документах)
https://thinkingrecords.co.uk/2025/06/27/records-management-in-a-hyperscale-digital-world/
