Comments 20
Wiki помогает быстрее заонбордиться, получить данные, узнать о процессах и регламентах, найти гайды и тд. А вот задачи борьбы с воровстком доков у нее нет.
Вторая опасность записана ниже. Корпоративная Wiki создаёт иллюзию знакомства с процессами и регламентами, однако не позволяет узнать реальные процессы и регламенты, которые во многих случаях нигде не записаны и основаны на многолетних негласных традициях и личных интригах.
Проще говоря! Когда сотрудник заонбордился, узнал о процессах, прочёл регламенты и гайды, он задаёт вопрос: почему эти регламенты работают не для всех и не всегда?
Формальная вики, сделанная для галочки - да. Менее формальная вики, которую пишут одновременно все - первый же новый сотрудник оставит пометку: фактически не применяется. Как убедить всех писать вики, вопрос отдельный и сложный.
А документы всегда можно телефоном отфотографировать. Если надо секретность, это обеспечивается закрытыми сетями и досмотром людей, а не ныканьем документов
первый же новый сотрудник оставит пометку: фактически не применяется
Почему же не применяется? Начальство требует сочинить инструкцию, поэтому она вполне применяется. И начальство требует выполнить инструкцию с пунктом «исполнять распоряжения», и она вполне выполняется. Распоряжения исполняются.
Просто исполняются распоряжения кого надо, а не всех подряд. И вот этого-то новичок не знает.
Согласен, что тема с защитой данных важна, для этого нужен хороший DLP. Он же может применяться и в связке с wiki (на уровне распределения доступов, например) - но это прямо совсем другая история, в этой статье все-таки про наш опыт структурирования знаний. Могу сказать только, что сейчас учетки ко всем системам у нас управляется из единой точки, а условно-секретные документы/разделы в wiki по умолчанию закрыты и доступ выдается вручную.
По поводу несоответствий регламентов и реальных процессов - у нас как то принято писать комментарием к статье или ее части, что "тут не актуально, поправьте пожалуйста" и мы правим :) Статьи устаревают и их надо периодически ревьювить, иногда мы просто ставим тег "актуализировать" (например времени прямщас поправить статью нет, а упускать не хочется) и по нему потом отсматриваем, что устарело: назначаем задачи сотруднкам или себе актуализировать такие вещи.
Большое спасибо за интересную статью! Мы тоже сейчас в процессе внедрения системы управления знаниями, ядором которой очевидно будет та или иная WiKi.
Не могли бы вы рассказать как вы решаете следующие проблемы/вопросы и какую систему (ПО) вы используете?
Как вы обеспечиваете контролируемое наполнение WiKi документами? На наш взгляд если не настроить процессы добавления и изменения документов, то очень скоро WiKi превратиться в большую свалку.
Как вы работаете с тегами? Сделли ли вы централизованно управляемую таксономию или же позволяете пользователям добавлять произвользные теги?
Буду весьма признателен за ответы. Вопросов у нас в процессе внедоения стоит очень много, а ответов пока нет. :)
1) Так же, как все контролируемые работы. Чтобы Wiki не превратилась в свалку, необходимо:
1.1) платить сотрудникам за то, чтобы она не превратилась,
1.2) нанять сотрудников для того, чтобы они не превращали,
1.3) навести порядок в работе.
Почему в вашей бухгалтерии нет большой свалки? По тем же причинам, которые станут работать и в Wiki.
2) Должна быть централизованная таксономия, потому что она удобна. Ещё лучше структурировать её в виде дерева.
В бухгалтерии нет свалки потому что в 1С очень жестко настроены и контролируются все процессы. Держать в порядке бухгалтерию без соотвествубщей информационной системы очень трудозатратно и сопряжено с большим количеством ошибок.
Я понимаю, что таксономия должны быть централизованной. Вам удалось ее реализовать? В том же Confluence невозможно сделать централизованное управление таксономией.
Хранение знаний и написание регламентов — стратегическая задача. А значит, задачи по наполнению попадают в квартальные цели руководителей, а они уже могут делегировать их своим сотрудникам. Конечно, написать доку и бросить — работа впустую, поэтому мы пишем письмо на команду/компанию, где рассказываем, что изменилось и как этой докой пользоваться. И часто еще проводим встречи по демонстрации результатов. А чтобы сохранить логику проводим ревью.
За организацию wiki конкретных проектов наших заказчиков отвечают руководители проекта, поэтому у них могут свои правила внутри команды появляться.
Руководители знают это ещё лучше. Они понимают, что после написания документов изменится главное: они перестанут быть руководителями, а их уникальные знания достанутся абы кому. Поэтому руководители не станут записывать в документах реальное положение дел, а запишут только формальное положение.
Руководитель напишет, что для получения реакции нужно обратиться по электронной почте. Однако руководитель не может написать, кто из браминов должен написать письмо, чтобы получить серьёзный ответ, и не напишет, почему письмо от парии получает только бессодержательные отписки. Руководитель не может этого написать, потому что при оглашении действительных порядков он сразу же потеряет власть над людьми.
Если не секрет, зачем вы работаете на таких проектах? Почему не встали и не ушли, когда поняли, что вами помыкают?
Тогда почему вы экстраполируете свой опыт работы в явно гос или полугоскомпании на всех? Я абсолютно уверен, что 99% того, что вы делаете на работе - чисто для галочки, и называть это работой в принципе странно
2) Я пишу в комментарии, что применение этого инструмента связано с определённым риском, и подробно раскрываю этот риск.
3) Вы отвечаете, что вся моя работа бесполезна. Но, простите, ваш вывод заметно притянутый. Ведь мы обсуждаем не конкретного человека, не вас и не меня. Мы обсуждаем опасную сторону инструмента, чтобы узнать, как избежать опасности. Вы же пишете не про инструмент, а про что-то совсем другое.
Отвечу за Вики по поводу тегов: у нас в компании нет хорошо настроенной практики работы с тегами в wiki.
Мы используем Confluence, а отсюда вытекает, что теги сотрудники могут ставить какие им захочется. И казалось бы это очевидная проблема, ожидается хаос и многообразие тегов, но нет: их вообще никто не ставит :)
У нас есть теги, которые мы используем для обозначения принадлежности регламента/раздела/статьи к системе ("outsource-CRM") или роли ("helpfull-for-PM"), но где-то они есть, где то нет. Так что теги - это большая точка роста для нас.
Пока самое полезное из тегов, что у нас есть (как я считаю), это метка/тег "актуализировать", по которой можно посмотреть и запланировать в работу исправления.
Когда исчезает неписаное знание традиций, сотрудники больше не могут быть разделены на браминов (которые обладают неписаным знанием традиций) и парий (которые не обладают негласным знанием традиций).
Когда сотрудники не могут быть разделены на браминов и парий, нарушается их взаимное подчинение. Брамины уже не могут приказать париям, а парии не подчиняются браминам. Парии начинают спорить с браминами. И тогда коллективом больше нельзя управлять.
Как действовать, чтобы одновременно сочетать базу корпоративных знаний, которые выступают формальной оболочкой, и обширную неписаную традицию, которая действительно управляет рабочими процессами? Если сотрудник прочёл всю базу корпоративных знаний и получил все знания о рабочих процессах, как же теперь объяснить ему, что он обязан выполнять все распоряжения, независимо от этих самых рабочих процессов?
Поясню на примере. В базе знаний указано, что научно-техническая библиотека работает с 10 до 14 и сотрудники могут выбрать книги по электронному каталогу. В действительности научно-техническая библиотека работает по предварительной телефонной заявке, причём у сотрудников нет доступа к электронному каталогу, а сам электронный каталог сделан в виде инвентарной книги. Как в этих условиях обеспечить нормальную работу базы знаний?
Спасибо.
Как в этих условиях обеспечить нормальную работу базы знаний?
Я начну с условий и контекста. Вы верите в этих ваших браминов и парий, традиции и опасности. И ищете подтверждение этому в вашей работе.
А я не верю. И строю свою работу так, как будто бы нет противостояния браминов и парий. И вопрос создания базы знаний для меня - вопрос времени, усилий, потенциальной пользы и заинтересованности других людей. Я не вижу моей выгоды в том, чтобы "зажать" информацию.
С контектом всё. Ответ на ваш вопрос - никак.
Пожалуйста.
База знаний wiki сохранит внутренние документы компании — как сделать ее удобной для пользования