Mundaneum Поля Отлє та Анрі Лафонтена був знищений нацистами. Та майже кожне сучасне підприємство здатне створити власний Манденіум, який міститиме усі знання, необхідні для забезпечення належного виконання, підвищення якості та відтворюваності бізнес-процесів, окремих операцій тощо. Зараз для цього потрібні, крім, звісно, бажання вищого керівництва, тільки методологія структурування знань та інформаційна система, яка дозволить реалізувати гнучке управління інформацією. Ну й, звісно, потрібен час на наповнення та підтримку такої системи.
Яким же ключовим вимогам має відповідати така інформаційна система?
По-перше, вона має дозволяти створювати окремі статті, що міститимуть відповідь на конкретне питання, або вимоги до конкретного результату, складової результату, тощо. Такі собі «інформаційні картки» Отлє, або ж «квантові», неподільні, документи.
По-друге, система має давати можливість «збирати» з таких квантових статей складені статті, що розкриватимуть, описуватимуть комплексні питання. Важливо, що при цьому йдеться не про гіпер-посилання (доречі, про гіпертекст Отлє теж писав), а про повне чи часткове, залежно від потреб, включення квантового документу у складений.
Поєднання цих двох властивостей системи дасть змогу документувати одну й ту саме інформацію лише один раз, що радикально спрощує управління інформацією в подальшому. Та, при цьому, дозволяє користувачеві читати не безліч окремих «карток», а, за потреби — суцільний складений документ.
Звісно, система має вміти відмічати квантові статті («картки») «анотаціями про род та вид інформації, що вони містять», як писав Отлє. А простіше та сучасніше кажучи — помічати статті тегами. Та було б непогано, щоб обирати з квантових статей ті, що потрібно «підтягнути» у складені — можна було за комбінацією потрібних тегів.
Джерело: Поль Отлє. Трактат про документацію, 1934, с. 42
Наша інформаційна система має давати аналітикам, що підтримують нормативну базу, можливість аналізувати взаємозв'язки та взаємовикористання квантованих та складених статей. Щоб, за потреби змінити щось в квантовій статті, розуміти, як це вплине на інші документи. А ще — редагувати статті за методом WYSIWYG: як аналітик бачить статтю під час редагування, так вона виглядатиме і для користувача.
Як заговорили про редагування, розглянемо ще одну важливу функціональну можливість. Одна і та сама інформація для різних цілей може бути викладена з різним рівнем деталізації. Наприклад, директор компанії не завжди має знати деталі порядку виконання окремого бізнес-процесу. А от власнику цього бізнес-процесу — потрібно розбиратись в процесі якомога глибше. Можна, звісно, написати (або зібрати з квантових) дві статті: одну із загальним описом, іншу — з детальним. Та краще (щоб не дублювати інформацію, звісно) було б написати (зібрати) одну статтю, яка б містила б одразу і узагальнення, і подробиці. Для цього система має давати можливість перемикати ступінь деталізації та «збирати» тексти статей так, щоб вони відображувались у різних режимах. Режими відображення стануть у нагоді і тоді, коли доведеться регламентувати, наприклад, процес, що може йти за різними сценаріями.
Очевидно, що для того, аби користувачам було простіше знайти відповіді на питання (наприклад, що і як робити в процесі? Які вимоги до результату? Хто є внутрішнім клієнтом? тощо), система має забезпечувати повнотекстовий пошук як за словами та виразами, так і за тегами. В ідеалі — вміти підключати пошукові засоби великих пошукових машин, на кшталт Google, щоб надати правильну відповідь навіть на неправильний (через неграмотність або друкарські помилки) запит.
Знання та нормативні вимоги швидко змінюються. Тож, щоб аналітики, які підтримують систему бізнес-процесів та її базу знань, якомога швидше дізнавались від користувачів (виконавців) про невідповідність регламентів реальності, система має давати можливість написати та обговорити пропозиції, зауваження до кожної статті.
Інколи не вдається одразу правильно викласти або змінити текст вимоги, регламенту, інструкції тощо. А ще, бува, змінений варіант — гірший за попередній. Відтак система має дозволяти зберігати історію виправлень, порівнювати версії статей, документів між собою, та повертатись до попередніх варіантів.