Pull to refresh

Comments 23

Просто KB? Не смешно. Коммиты в коде отдельно, планы развития и всякий слабоструктурированный хлам вроде исследования отдельно, сопроводительная документация отдельно, регламенты на типовые (и нетиповые, но известные) ситуации — отдельно, юридические документы отдельно.
Вообще, не было думал пересказывать здесь свое техническое задание. Целью было поделиться практическим опытом. Если интересуют какие-то моменты в реализации — готов поделиться. На данным момент даже не понятно насколько тема вызывает отклик.
В таком контексте — нет. Организация работы ИТ-отдела (когда в нём больше, чем сисадмин и эникейщик) — это очень сложная область, и разбирать только KB — смысла?
Разделяй и властвуй. А если смотреть на KB в разрезе ITIL'я, то дать унифицированный совет и написать статью «для всех и каждого» почти нереально. В таком случае, руководствуясь Вашим подходом, общих слов, будет еще больше.
Вы просто неправильно генерализируете задачу. KB используется в куче разных случаев, подгонять которые под единый ответ — ошибка.
Вы правы. KB имеет смысл внедрять так, чтобы использовать его во всем IT процессе. Например, у нас реализована функция линковая статей к инцидентам. Это штука реально помогает в тех случаях, когда определенные инциденты теряются в общей массе и не дают увидеть существующую проблему. Выгружая репорты по наиболее линкованым статьям, можно узнать много нового о своих системах. И это только один из примеров.
Жаль, что вся статья сводится к: KB должна быть очень хорошая, если будет плохая, то будет плохо.
Хотелось бы живых примеров. Я уже давно хочу создать KB, но так но так и не решил с какой стороны подходить. Учитывая, что денег на это явно выделать много не будут.
Как вести документы это одно. А как организовать, другое. Например, создание шаблонов, ведение инцидентов.
Начните с целесообразности: сколько у вас сотрудников? Нужно ли учить бизнес или же только IT? Посчитайте количество контактов друг с другом. Не могу сказать, какое количество будет критическим, чтобы принять положительное решение по KB, но у нас этих контактов более 1000 в месяц. Так же имеет смысл просто пообщаться с заинтересованными людьми: видят ли они смысл тратить на это время? KB в моем понимании — чтобы решать проблемы. Не думаю, что даже самое красивое средство даст больше возможностей, чем обычные тренинг материалы в виде презентаций.
На какой стадии обсуждения Knowledge Management у вас?
Я планирую его использовать для ведения внутренней документации IT отдела. Ведение правильной документации по оборудованию, софту, инцидентам. Хочется видеть некий справочник IT проблем и решений в компании.
То есть размах, конечно, небольшой.
Если на данный момент ничего из упомянутого у вас в организованном виде нет, то думаю, что имеет смысл начать с изучения банальных азов ITIL. Идея иметь все в одном месте правильная. Но идея начинать с Knowledge Management'а не самая удачная, на мой взгляд. Ведь смысл не в том, чтобы сложить в одну кучу презенташки и назвать это базой знаний, хотя в каком-то смысле это и так, а в том, чтобы иметь возможность легко завязывать это с теми же инцидентами, проблемами и конфигурациями. Банально, иметь возможность линковать все друг с другом на уровне приложеними.
Правильно. Я это и хочу. Не спорю, что нужно мне изучить и ITIL. Но на данном этапе мне очень хочется заиметь программу, которая бы которая увязывала бы физический уровень, логический и инциденты. Ну и связи, конечно.
Похоже, модно стало писать подобные статьи с многообещающим заголовком и всем известной водой внутри.
Все, о чем я писал, было на основе реальных проблем, с которыми мы столкнулись. Если Вам это известно, то, уверен, что Ваш опыт во много раз больше моего. Чего важного я упустил, что могло бы быть полезно? Готов убрать «многообещаемость» и ответить на конкретные вопросы. Пока ни одного не было, кроме как о том, с чего начать.
Был бы рад конкретике. Какими продуктами вы пользовались для создания КВ? Платформа, сервер, самописные скрипты, Wiki или что?
В качестве IT Service платформы у нас используется Service Now. Достаточно гибкое веб приложение с хорошим wiki на офф сайте. Вот тут можно посмотреть на саму систему.

Пробежался быстро по демо версии, насколько увидел там больше тикетная система чем База знаний. Как раз выбираем базу знаний и ничего подходящего пока не нашли, тикетная система уж внедрена и работает!
Та же головная боль. Надо где то вести документацию. Wiki явно не оченб подходят под эту роль. Вариант — можно заточить sharepoint, но чуство, что стрельба из пушки по воробьям. Да и хотелось бы OpenSource решение.
Sharepoint как раз больше подходит именно для хранения тренингов и документаций. Не нужно парится с пермишанами, дизайном и прочей рутиной. Но для KB не лучший вариант. Интеграция Share Point'а в свои приложения в любом случае не сахар. Если только для тикетов Вы не используете что-то майкросовтовское типо Dymanic CRM, как я пытался делать до этого. Но на тот момент передо мной не стояло целью организовать KB.
Если стоит целью выбрать сторонние готовые решения для Базы знаний и использовать ее только для этого, то конечно Service Now не вариант. Но мне в целом нравится идея иметь в одной системе разные сущности (таблицы) для каждого из процессов: инциденты, знания, change request'ы и прочее, которые линкуются друг с другом по ID.
Может Вам есть смысл добавить функциональность KB прамо в Вашу тикетную систему? Будет много легче приучить людей, туда заходить. Да использовать интерфейс и категоризацию, к которой люди уже привыкли, существенно проще.
Нашли что нибудь?
Если речь идёт именно о знаниях (а не о библиотеке документов), то необходимо:
1. чтобы в базе была уникальная информация, недоступная другими способами (зачем сотруднику туда заходить?)
2. чтобы руководство мотивировало и поощряло пишущих (зачем сотруднику писать?)

Также стоит донести мысль что полезным является не только написание, но и редактирование, уточнение, поддержание в актуальном состоянии.
Sign up to leave a comment.

Articles