На протяжении всей книги я возвращаюсь к одной и той же мысли - люди не всегда хотят изменить что-то в своём восприятии окружающей действительности. Корпоративная память и выживание фирмы на рынке зависят от грамотной организации записей компании, но некоторые по-прежнему считают функции, связанные с управлением записями, простым перекладыванием бумаг с мета на место - чем-то, что происходит в стороне от «более важных» дел. Как говорил писатель Викторианской эпохи A.H. Clough, «с глаз долой - из сердца вон».
Есть ещё одна сторона жизни компании, о которой обычно редко вспоминают. Это - политика фирмы. Её письменное изложение может храниться в файле, печататься в необъятных руководствах, которые без толку пылятся на полке, поскольку ни у кого нет времени их читать; его можно даже вставить в рамку красного дерева и повесить на стену в зале заседаний,где оно уже больше никогда не обратит на себя чьего-либо внимания. Политика - жизненно важный элемент деятельности организации, но она, как правило, не бросается в глаза до тех пор, пока у кого-нибудь не возникнет вопрос относительно действий организации на рынке.
Эта глава проливает свет на функции управления записями и на политику фирмы, чтобы продемонстрировать, как политика и система управления документацией взаимодействуют друг с другом и с самой компанией. Внедрение СУДФ должно следовать за разработкой политики фирмы. Кроме того, в обоих этих начинаниях потребуется помощь разработчика документации - человека, который появляется на сцене, когда заходит речь о переходе на СУДФ, и играет в этом процессе немаловажную роль. Поэтому в этой главе рассматриваются также некоторые возможные функции, которые выполняет разработчик документации в ходе проектирования и внедрения СУДФ.
СТРУКТУРА ПОЛИТИКИ ФИРМЫ В ОТНОШЕНИИ РАЗРАБОТКИ ДОКУМЕНТАЦИИ
В этом разделе рассматривается структура политики фирмы в отношении разработки документации, в том числе некоторые общие принципы построения политики управления документацией фирмы (ПУДФ) и ключевые элементы ПУДФ.
Общие принципы
В организации могут забыть о политике по многим причинам. Прежде всего, направления политики излагаются, как правило, в формальной юридической документации, которая,на первый взгляд, имеет мало отношения к реальному бизнесу. Такая терминологическая неразбериха идёт ещё от самых корней политики, которая зарождалась из статей законов, касающихся деятельности компаний, а также законов и подзаконных актов, регулирующих деятельность министерств. Ещё одна причина подобного отношения - неопределённость. Политика фирмы декларируется временами настолько обобщенно и неконкретно, что в результате она и на самом деле оказывается никак не связана с реальной деятельностью компании.
Среди причин незаметности политики фирмы есть и такая,которая не представляет собой проблемы. Если политика разработана грамотно, то постоянно напоминать о ней нет никакой необходимости - она настолько тесно связана со структурой организации предприятия, его предназначением, целями и деятельностью, что каждый шаг, предпринимаемый этой компанией в бизнесе, сам по себе уже является выражением её политики. Останавливаться подробно на положениях этой политики необходимо только в случае внесения в неё изменений или при инструктаже нового сотрудника. Конечно, такую политику можно считать образцовой, изменяется она не часто, и всё это может происходить только на идеальном предприятии,которое мало кому из нас доведётся когда-то увидеть. Основная идея качественной ПУДФ, как и любой другой грамотно разработанной политики, состоит в том, что она должна вносить непосредственный вклад в достижение целей предприятия.
Кроме того, ПУДФ должна быть согласованной. Возьмём для примера вариант политики предприятия в отношении архитектуры документации - политику принятия и дальнейшего использования языка SGML в элементах составных документов. Такая политика должна быть согласована с архитектурой баз данных предприятия - например, можно внедрить СУБД для хранения как элементов данных, так и элементов составных документов.
Как уже было сказано выше, грамотно разработанная политика может стать заметной. Это не означает, что её не обязательно записывать, или читать и разбираться в ней, или что нет необходимости обучать ей сотрудников. ПУДФ обязательно должна быть изложена в письменном виде. Если политика настолько сложна, что записать её положения невозможно, значит для сотрудников она останется в лучшем случае непонятной; впрочем, письменный вариант политики не обязательно облегчает её понимание. Направления политики должны быть изложены чётко, ясно и кратко.
Кроме того, запись о ПУДФ должна находиться в хранилище системы управления документацией фирмы, чтобы каждый мог с ней ознакомиться. Формулировка положений политики и предоставление доступа к ней всем сотрудникам организации предполагает, что должен действовать принцип «увидеть - значит поверить». Размещение письменного изложения политики фирмы в СУДФ усиливает взаимосвязь между самой политикой и предметом её регулирования - политика действует во благо системы и наоборот. Доступность соответствующей информации поможет решить проблему неопределённости и несогласованности интерпретации и применения положений политики.
Она создаст атмосферу доверия в свете новых методов принятия решений. ПУДФ - это лучший способ заставить систему управления документацией фирмы работать во благо этой фирмы. Элементы политики управления документацией фирмы
Процесс разработки политики продвигается, как правило,по направлению от общего к частному. В этом разделе речь идёт об общих положениях политики управления документацией фирмы. Дальше будут рассмотрены отдельные направления,регулирующие работу с переходными записями, с электронной почтой и уничтожение записей.
Хотя компоненты политики в разных организациях могут именоваться по-разному, любая ПУДФ содержит следующие элементы, которые я называю так:
<![if !supportLists]>· <![endif]>Назначение: причина существования политики
<![if !supportLists]>· <![endif]>Цель: описание действий предприятия по проведению политики в жизнь
<![if !supportLists]>· <![endif]>Определения: употребляемые термины и их значения
<![if !supportLists]>· <![endif]>Декларация масштабов: рамки, в которых действуют положения политики
<![if !supportLists]>· <![endif]>Правила проведения: базовые принципы, на которых основываются методы управления документацией
<![if !supportLists]>· <![endif]>Власть: распределение полномочий в процессе проведения политики в жизнь
<![if !supportLists]>· <![endif]>Пересмотр и обновление: определение правомочности внесения изменений в политику и условий, при которых её следует изменять
Положения политики могут быть записаны в разделах под соответствующими заголовками или в любой другой форме, но все названные элементы - независимо от того, как Вы их назовёте, - следует принять во внимание и учесть при формировании ПУДФ.
Назначение
Прежде всего, давайте рассмотрим назначение общей ПУДФ как таковой, а затем перейдём к обсуждению компонентов,которые должны входить в декларацию о назначении политики. Общее назначение ПУДФ включает в себя ряд элементов:
<![if !supportLists]>· <![endif]>В основе политики лежит понимание той существенной роли, которую документы играют в достижении предприятием успеха, а также в разработке, использовании и распространении знаний внутри компании.
<![if !supportLists]>· <![endif]>Управление документацией должно способствовать выполнению миссий и обязательств предприятия, а также работать во благо клиентов фирмы.
<![if !supportLists]>· <![endif]>В положениях политики должны оговариваться фундаментальные правила, в соответствии с которыми предприятие планирует создавать, сохранять и находить документы.
<![if !supportLists]>· <![endif]>В положениях политики представлены наиболее общие принципы, которыми следует руководствоваться Директору по информации (Chief information officer) при организации управления информационными ресурсами компании и, в том числе, документами.
<![if !supportLists]>· <![endif]>Посредством проведения в жизнь своей политики предприятие должно продвигать идею о том, что информация, содержащаяся в документах, даёт сотрудникам пищу для размышлений, и результатом должны стать принципиально новые решения и подходы.
Декларация о назначении реальной политики может содержать эти пункты. Кроме того, она должна включать в себя чёткое перечисление основных правил, принципов, факторов достижения успеха, инноваций и выгод, определяющих проведение в жизнь этой политики. Когда назначение политики станет ясным и понятным, его можно использовать как основу для приобретения предприятием ресурсов для системы управления документацией.
Цель
Декларация целей политики тесно связана с её назначением. Цель ПУДФ состоит в том, чтобы обеспечить наиболее выгодный способ использования документации для выполнения предприятием его миссии. Предполагается, что, посредством проведения в жизнь своей политики, организация сумеет заметно усовершенствовать методы использования имеющихся знаний, документов и методов управления.
Определения
Раздел ПУДФ, касающийся определений, должен содержать краткие, не допускающие вариантов трактовки объяснения и описания терминов, значения которых не очевидны.
Определённые правила и идеи, которые очевидны для людей и в системах управления записями в бумажном представлении,должны быть отдельно объяснены в СУДФ. (Этот вопрос более подробно рассмотрен в других главах). Таким терминам, как оригинал, публикация, переходная запись, документ, электронная почта, версия, черновой и окончательный вариант документа и официальная запись, необходимо дать определения,чтобы сотрудник, который создаёт документ, знал, что с ним следует делать в соответствии с положениями политики фирмы.
Масштаб
Масштаб начинания зависит от того, как и где на предприятии внедряется СУДФ. Политика может относиться к отдельной программе или организационному подразделению компании, где есть возможность протестировать пилотную версию системы, или ко всей фирме сразу. Кроме того, расширенный вариант политики может затрагивать партнёров, клиентов фирмы и другие компании. Естественно, необходимо определить группы, на которые повлияет политика фирмы.
Правила проведения
Правила проведения определяют структуру внедрения системы управления документацией в охваченных проектом организационных подразделениях предприятия. Структура должна затрагивать следующие направления:
<![if !supportLists]>· <![endif]>Отчётность: Предприятие будет применять разумные принципы в отношении управления хранилищами документации и в стратегических масштабах развивать модели, технологии и подходы, по образцу которых должна строиться отчётность менеджеров, служащих и клиентов компании.
<![if !supportLists]>· <![endif]>Собственность компании: Документы, полученные менеджерами или другими сотрудниками, выступающими от лица компании, считаются собственностью и ресурсами организации, если эти документы не защищены авторским правом.
<![if !supportLists]>· <![endif]>Совместное пользование документами: Содержащаяся в документах информация считается общественной собственностью предприятия, к которой служащие и менеджеры фирмы имеют доступ по мере необходимости. Предполагается, что сотрудники компании должны обеспечивать адекватное использование информации и отсутствие злоупотреблений.
<![if !supportLists]>· <![endif]>Экономия информации: Предприятию следует пользоваться наилучшими из доступных источников документов по наиболее экономным расценкам независимо от того, принадлежат ли уже эти документы организации, принимаются извне как открытая информация или на тех или иных условиях обмена принимаются от других организаций.
<![if !supportLists]>· <![endif]>Поддержка: При внедрении любой СУДФ необходимо удостовериться в том, что ресурсов сети достаточно для поддержки системы в работоспособном состоянии и на должном уровне в течение всего срока её эксплуатации.
<![if !supportLists]>· <![endif]>Причастность сотрудников: Внедрение СУДФ следует осуществлять таким образом, чтобы у сотрудников была возможность внести свою лепту в достижение корпоративных целей. Пусть они примут участие в процессе изменений,получат в то же время необходимые знания и навыки в работе с технологиями управления документацией и разработают новые методики использования СУДФ для принятия решений и обслуживания сотрудников компании.
<![if !supportLists]>· <![endif]>Стандарты: Необходимо использовать и проводить в жизнь все виды стандартов - международный, национальный и де-факто - чтобы создать благоприятную среду для совместного использования документов, размещённых в хранилище. Стандарты позволяют осуществлять обмен документацией наиболее продуктивно.
<![if !supportLists]>· <![endif]>Поддерживаемость: Предприятию следует максимально использовать содержащуюся в документах информацию и соответствующую технологию управления документами во благо своего процветания в бизнесе и получения доходов.
<![if !supportLists]>· <![endif]>Полезность: Электронную систему управления документацией следует внедрять в соответствии с административными и оперативными потребностями предприятия. Предполагается, что СУДФ существенно усилит компанию.
Полномочия
В декларации полномочий очерчиваются рамки полномочий различных сотрудников в процессе осуществления политики в целом и, по мере необходимости, в различных подразделениях и на разных уровнях предприятия. Как правило, общее руководство поручается директору по информации, в обязанности которого входит контроль политики и разработка программ, процедур и правил, согласующихся с обозначенными в положениях политики принципами.
Иногда возникает необходимость на время (например, в отсутствие директора по информации) или насовсем (в соответствии с определёнными потребностями предприятия) передать кому-то полномочия по управлению проектом. В декларации полномочий оговаривается и эта ситуация. Типичная формулировка в письменном изложении политики гласит: «Директор по информации может делегировать любую часть своих полномочий в соответствии с положениями данной политики соответствующему представителю менеджмента или другому сотруднику организации. Директор по информации может перепоручить проведение в жизнь политики фирмы в соответствии с наилучшими принятыми на предприятии принципами менеджмента». Все руководители отделов и подразделений компании должны нести ответственность за соблюдение принципов и направлений политики при управлении порученными им документами.
Пересмотр и обновление
Политику фирмы следует пересматривать ежегодно и вносить в неё изменения, основываясь на рекомендациях руководителей подразделений директору по информации. Полномочия директора по информации в этом сегменте политики предприятия могут быть расширены вплоть до предоставления ему права самостоятельного пересмотра политики; в некоторых организациях, однако, может возникнуть необходимость передавать рекомендации непосредственно в комитет администрации компании для принятия окончательного решения.
Руководствуясь приведённой здесь структурой и рассмотренными нами общими принципами построения политики фирмы, Вы можете приступать к подготовке ПУДФ для Вашей компании. Это не полный, законченный образец политики, который можно без изменений перенести в конкретные условия любой организации. Что именно будет представлять собой окончательный вариант политики в Вашем случае, будет зависеть от того, какого рода попытки в этом направлении уже предпринимались в компании, какие правила существуют на этот счёт,насколько хорошо специалисты по разработке политики знают своё дело, как организован процесс пересмотра политики, а главное от самого Вашего предприятия - что оно собой представляет и чем занимается.
Другие сопутствующие направления политики
Помимо общих направлений ПУДФ, Вам потребуется разработать и отдельные сегменты политики, регулирующие каждую область управления документацией. Ниже приведены некоторые идеи по организации политики в отношении переходных записей, электронной почты и уничтожения официальных записей.
Переходные записи
Переходные записи используются для отслеживания за выполнением и подготовкой определённых действий. Переходные записи и документы о выполняющейся работе помогают в принятии решений, проведении политики фирмы в жизнь, а также дают возможность получить необходимую справку о деятельности компании, но при этом они не входят в число официальных записей. Некоторые из них в конечном итоге могут приобрести официальный статус, если они будут переведены в разряд формальной документации или опубликованы для широкой публики. Такие записи следует помещать в хранилище,но только на определённый срок. Как правило, через 6-12 месяцев после их создания они пересматриваются, и принимается решение об их переходе в категорию официальных записей или об их уничтожении.
Переходные записи обычно не подшиваются в папку, кроме тех случаев, когда на них записан комментарий, резолюция, или когда к записи прикреплена какая-либо другая информация, например, карточка с указанием, куда дальше необходимо передать документ. В этом случае документ считается официальной записью, и его необходимо положить на хранение в папку.
Обычно за уничтожение или вывод из обращения переходной записи отвечает тот сотрудник, который её создал. В некоторых организациях, однако, практикуется несколько другая система - соответствующее решение принимают специалисты по управлению записями.
Электронная почта
Для электронной почты необходимо разработать отдельное направление политики, где будет определено, в каких случаях письма следует считать переходными записями, в каких - официальными, и как с ними следует обращаться. В положениях политики также должно быть указано, каким образом файлы,прикреплённые к посланиям электронной почты, должны добавляться в корпоративное хранилище или изыматься оттуда.
Электронная почта по своей сути является средством передачи сообщений, но со временем она всё больше используется в процессе принятия решений для взаимосвязи заинтересованных сторон. Во многих организациях, как в государственном,так и в частном секторе электронная почта напоминает чёрную дыру, где ценные записи компании бесследно пропадают во тьме электронного мусорного ящика; официальные записи о многих сделках приходится стирать из-за отсутствия свободного места на диске. На самом деле, отслеживание прикрепленных к посланиям электронной почты (например, при помощи электронных скрепок) файлов - это серьёзная задача для существующих приложений СУДФ.
Уничтожение официальных записей
Для управления уничтожением официальных записей тоже необходимо разработать отдельное направление политики.Обычно за уничтожение записей отвечает группа управления или администрирования записей. Существует насущная необходимость просматривать записи с точки зрения их юридической ценности, чтобы определить, нет ли смысла сохранить их в архиве, а также чтобы проверить, нет ведётся ли судебного процесса, где эти документы могут пригодиться. Поэтому не следует давать отдельным сотрудникам полномочий уничтожать официальную запись после того, как она была внесена в хранилище.
Администратору записей следует стирать официальную запись из корпоративного хранилища только тогда, когда на то есть веская причина. И даже в этом случае должна оставаться возможность установить, что такой документ существовал и был уничтожен.
ОБНАРОДОВАНИЕ ПОЛИТИКИ
Политику необходимо разъяснять, и ПУДФ - не исключение. Она не может быть ясной сама по себе по той простой причине, что система управления документацией основывается на новых концепциях. Необходимо давать разъяснения, толкования, обучать ей сотрудников, чтобы создать атмосферу понимания и доверия. Следует разработать механизм обратной связи, чтобы была возможность отвечать на вопросы и разъяснять положения политики.
ПУДФ должна быть гибкой и открытой для изменений.
Вернёмся к рассматривавшемуся нами выше примеру политики, в которой утверждалось, что архитектура составных документов компании должна базироваться на формате SGML. Если произойдут изменения в ценности или общепринятости SGMLи на первый план выйдут форматы HTML, OLE или OpenDoc,то необходимо будет внести соответствующие поправки и в политику, чтобы она отражала новый принятый стандарт или сосуществование ряда стандартов. ПУДФ не может оставаться неизменной, она должна отражать развитие получающей распространение дисциплины - разработки документации.
Необходимо отличать ПУДФ от процедур и правил. Например, если политика требует использовать стандарт HTML для всех документов, размещённых на корпоративном узле World Wide Web (WWW), то должны быть разработаны соответствующие процедуры и правила, устанавливающие стандарт непосредственного применения HTML на домашней странице и в других объектах. Такого рода правила никогда не вписываются в положения самой политики, поскольку они гораздо чаще подвергаются изменениям по мере появления новых технологий рационализации и разработки.
И, наконец, не забывайте о том, что все направления политики необходимо контролировать. Такой контроль должен осуществляться не на уровне рядовых аналитиков; им должен руководить представитель администрации фирмы, оказывающий поддержку начинанию, которые понимает, какое влияние политика оказывает на сотрудников нижнего уровня иерархии предприятия.
Возьмём для наглядности гипотетический вариант развития событий в примере со стандартом SGML. ИспользованиеSGML позволяет увеличить область поиска документов посредством внесения фрагментов текстов в СУБД или систему управления текстами (СУТ). Параграфы, списки, предложения,главы, разделы и тому подобные элементы можно использовать для увеличения точности поиска и в то же время снижения количества неверных попаданий. Теперь давайте предположим,что группа обработки информации пытается перевести системы и проекты предприятия на объектно-ориентированную СУБД.
Одно из подразделений группы обработки информации разрабатывает политику, которая противоречит ПУДФ, требуя, чтобы для хранения всех объектов использовалась объектно-ориентированная СУБД, а не просто СУБД или СУТ.
Возникает проблема, которую невозможно разрешить на уровне группы или подразделения. Внесение изменений в политику должно контролироваться на самом высоком уровне иерархии предприятия. Необходимо проанализировать существующую и предлагающуюся политику и представить результаты анализа руководителям компании, отвечающим за осуществление проекта, чтобы они приняли разумное, не влекущее за собой больших затрат единое решение о переводе организации на более мощную систему объектной ориентации и о приостановке вложений в технологии и средства СУБД.
Как видите, ПУДФ, её различные воплощения и связанные с ней аспекты деятельности предприятия - непростая тема.
И всё же грамотная ПУДФ необходима фирме, и уж во всяком случае, попытки вести дела без чётко выстроенной структуры политики не выдерживают никакой конкуренции. На самом деле, в отсутствие структуры политики невозможно добиться правильного подхода к деятельности предприятия. Инвестиции в разработку политики компании не менее важны, чем вложения средств в СУДФ как таковую.
РОЛЬ РАЗРАБОТЧИКА ДОКУМЕНТАЦИИ
Для успешной разработки и внедрения СУДФ необходимо вкладывать средства и в высококвалифицированных специалистов. Исторически так сложилось, что ключевые роли в информационном менеджменте организации выполняли разработчики информации, моделей данных, самих данных и систем. С развитием СУДФ появляется новая категория специалистов разработчики документации.
Организации ещё не определили окончательно функции разработчика документации. В этом разделе рассматриваются возможные права и обязанности разработчика документации на предприятии, а также навыки и качества, которыми необходимо обладать человеку, чтобы добиться успеха в этой роли.
При переходе на СУДФ организация может пойти двумя различными путями. Первый вариант - нанять разработчика документации на должность менеджера или руководителя проекта, и тогда он будет полноправным членом команды разработки. Второй - пригласить специалиста по разработке документации поучаствовать в проекте в роли консультанта, а руководство и управление проектом поручить другим опытным сотрудникам предприятия. Какой из этих вариантов выберет каждое конкретное предприятие, зависит от обстоятельств, а они в каждом случае свои. Тем не менее, Вы сможете принять решение с большей уверенностью, если примете во внимание существенные различия между ролями руководителя проекта и консультанта.
Руководитель проекта
Выбирая руководителя команды разработки СУДФ, организация определяет, кто будет направлять рутинную деятельность команды. Руководитель команды принимает на себя ответственность по ряду вопросов: определить цели проекта, подготовить декларацию предназначения и обязательств команды,помочь проследить цели и достижения команды и так далее.
Руководитель определяет, какие ресурсы необходимы для осуществления проекта. В этом качестве руководитель, вероятно, отберёт консультантов и квалифицированных членов команды, которые присоединятся к проекту, а также поможет сотрудникам приобрести необходимые навыки.
Руководитель также выступает в роли точки соприкосновения команды разработки и остальных сотрудников предприятия, так как он, в числе проч ыскивает помещения для собраний, офисы, компьютерное оборудование и расходные материалы. В дальнейшем руководитель официально отвечает за записи проекта, корреспонденцию, протоколы, списки вопросов на повестке дня, презентации, вспомогательные материалы и так далее. (Конечно, если Вы решите, что это не работа, а кошмар, то лучше предусмотрите в бюджете возможность нанять ассистента, который поможет руководителю справиться). Кроме того, руководитель сохраняет полномочия менеджера, вследствие чего он может немедленно осуществить любые изменения, лежащие в пределах его компетенции. Разрешение на всё остальные изменения необходимо получать отдельно на соответствующем уровне руководства предприятием.
В итоге руководитель команды разработки СУДФ выполняет многие из функций, которые традиционно ассоциируются у нас с должностью менеджера или руководителя проекта.
В первую очередь, однако, этому специалисту необходимо сосредоточиться на задачах и достижениях в области разработки документации.
Консультант
Когда организация приглашает специалиста по разработке документации на должность консультанта, фокус его активности смещается с непосредственного руководства проектом к предоставлению помощи и совета. Консультант наблюдает за проектом в целом, но он не обязательно должен принимать участие в рутинной работе. Для роли консультанта характерны две основные черты - он сосредотачивается на процессе, который в проекте СУДФ более важен, нежели индивидуальные задания, и работает с методами принятия решений, а также определением необходимых решений (результатов).
Консультант помогает руководителю команды структуризировать задания и распределить их среди сотрудников, а также оценивает и переоценивает потребность в различных ресурсах для завершения проекта. Он помогает разъяснить принципы разработки документации другим членам команды и демонстрирует им, как эти принципы применяются на предприятии.
Консультант помогает членам команды освоиться с терминологией разработки документации и понять, какими должны быть результаты. Таким образом консультант помогает членам команды развить способность к пониманию и внедрению принципов разработки документации. Кроме того, консультант использует свои личные и профессиональные навыки для упрощения процесса и планирования, чтобы направить усилия членов команды в нужное русло для успешного достижения результатов.
Среди других обязанностей следует упомянуть информирование высшего руководства фирмы о продвижении проекта и оказание помощи в анализе запросов к СУДФ с точки зрения бизнеса. В промежутках между собраниями консультант работает с руководителем проекта, помогая ему подготовиться к следующей встрече.
Хорошо зная стадии жизненного цикла разработки документации, консультант помогает членам команды понять, как жизненный цикл влияет на результаты проекта. С помощью консультанта члены команды определяют значение параметров и оценивают их значение для всего начинания. Соблюдение стандартов безопасности СУДФ и выполнение соответствующих процедур также входит в обязанности консультанта. Она разрабатывает расширенные системы классификации файлов, которые позволяют свести в единую структуру документы на бумаге, в электронном виде и в микроформе.
Консультанту обычно оказывают содействие технические специалисты - сами консультанты редко бывают технически подкованы - и с их помощью он исследует альтернативные варианты технических решений, оценивает адекватность архитектуры сети и даёт рекомендации относительно необходимых изменений. Консультант должен обеспечивать баланс соотношения цена/качество для предприятия. Когда приходит срок,консультант обеспечивает запуск и начало работы электронного хранилища, а также устанавливает процедуры поддержки и администрирования.
В общем и целом, консультант занимается тем, что даёт советы, а не руководит и не управляет. Контроль и администрирование проекта могут быть поручены временному сотруднику на должности менеджера проекта.
Необходимые навыки
Независимо от того, выступает разработчик документов в роли руководителя или консультанта, ему необходимо обладать определёнными навыками. Для достижения успеха в выбранной области ему потребуется умение работать как с людьми,так и с техникой. Конечно, редкий человек обладает всеми перечисленными здесь квалификациями - настолько редкий,что кто-то из Вас, возможно, даже предположит, что таких людей вовсе не бывает. И всё-таки, чем талантливее и опытнее человек, тем лучше для проекта и для предприятия.
Навыки в работе с людьми
Черты личности и коммуникативные способности, которые принято называть умением работать с людьми, включают в себя высокую чувствительность, умение слушать, целостность личности, умение принимать решения, настойчивость, воодушевление, новаторство и образованность. Все эти качества необходимы специалисту по разработке документации.
Разработчик документации, действующий в интересах людей, должен уметь правильно реагировать на замечания и требования подчинённых и начальства. Если он будет равнодушен к потребностям других, то он рискует потерять - а вероятнее всего, терять раз за разом - важнейший ресурс команды - её членов. Но, кроме того, разработчик документации должен уметь отделять важные потребности от всех остальных и не допускать того, чтобы члены команды или руководители проекта сводили обсуждение общих задач и проблем к разговору о требованиях отдельных людей или проектов.
Серьёзный специалист по разработке документации полностью посвящает себя своим сотрудникам, клиентам и работе не обязательно в таком порядке. Он должен служить примером безоговорочного следования принятому курсу, даже если это означает, что придётся встать одному против всех, и должен быть готов признать свои ошибки, потому что нельзя допустить, чтобы из-за самолюбия не был достигнут наилучший для клиента результат. Обязательность и твёрдость идут рука об руку с решительностью. Если возникает необходимость принять жёсткое или непопулярное решение относительно качества, ресурсов или графика, разработчик документации должен быть готов принять на себя соответствующие риски, и в его задачу входит пройти через все преграды и препятствия, чтобы достигнуть целей и выполнить предназначение проекта.
Наряду со всем этим, разработчик документации должен воодушевлять команду, чтобы та полностью выкладывалась ради получения результатов, достигнуть которых иным способом невозможно. Члены команды должны продемонстрировать требовательное отношение к деталям, неприятие проявлений посредственности и железную дисциплину. Новые технологии в среде клиент/сервер не позволят членам команды «изображать»решение проблемы - им придётся на самом деле её решать.
Талантливый руководитель сумеет внушить членам команды чувство безопасности, солидарности и сплочённости. Естественно, за умением вдохновить следует способность демонстрировать зарождение новых идей через креативное мышление.
Все гипотезы необходимо ставить под сомнение, в то время как перспективные возможности команде необходимо исследовать,чтобы выбрать эффективное и действенное решение.
На этом этапе Вы, возможно, подумываете о том, чтобы подыскать идеального специалиста по разработке документации вне Вашей организации. (Многие именно так и делают, иначе я бы не занимался тем, чем занимаюсь!) Если это так, и даже если в штате Вашей компании уже есть подходящий человек,
Вам всё равно нужно выбрать людей на роли остальных участников проекта. Несомненно, в их число должны входить сотрудники компании, которые впоследствии станут внутренними экспертами организации.
Как уже говорилось выше, разработка СУДФ - не лучшее время для обучения по ходу работы. Теперь пора рассмотреть этот вопрос немного подробнее. Вы, разумеется, не хотели бы накликать беду на важный и дорогостоящий проект, поставив во главе команды разработки совершенно некомпетентного и неопытного человека или собрав всю команду из таких людей. Не получится, однако, полностью избежать обучения по ходу работы, по той простой причине, что речь идёт о новой области деятельности, и опытных специалистов в этой сфере пока что очень мало. Так что, если набрать в команду сотрудников,обладающих соответствующими способностями, опытом и знаниями в сопутствующих областях, а также энтузиазмом, опытный специалист по разработке документации сумеет обучить их в процессе осуществления проекта и обеспечения работоспособности программного обеспечения.
Члены команды должны развивать в себе необходимые навыки, обучаясь у разработчика документации его мастерству в процессе перехода на СУДФ. И опять же, так как речь идёт о новой - и для предприятия в том числе - области, многих тонкостей, концепций и подходов команда не узнает до тех пор,пока проект не начнёт действовать; и многие сферы, с которыми команде предстоит соприкоснуться, будут обойдены вниманием разработчика документации, если он не входит в число наиболее опытных в этой области специалистов. Сотрудники должен иметь возможность внести свой вклад в переход на новую систему, но они не могут в полной мере принять участие в деле, если заранее не приобретут новых, радикальных навыков и не будут посвящены в тайны профессии.
Избитая фраза о корпоративном тренинге гласит: «Незнание дорого, а обучение недёшево». Перед проведением тренинга для членов команды необходимо разработать план и определить, каких результатов можно ожидать. В отсутствие плана обучение будет в лучшем случае запутанным, а в худшем - противоречивым.
В ходе тренинга разработчик документации должен ознакомить сотрудников компании с новыми технологиями анализа, применяющимися в работе со структурированными документами, и с архитектурой составных документов. Новые технологии проектирования помогут обучающемуся персоналу разобраться в компонентах СУДФ и в способах настройки системы для работы с редким или сложным программным обеспечением на машине клиента. Обучение такого рода очень специфично и ограничено только нуждами проекта. Последующий тренинг может включать в себя более общепринятые курсы для приобретения опыта работы с проектом. В дальнейшем навыки разработчика документации в работе с людьми и с техникой можно передать участникам проекта, чтобы повысить их мотивацию, гарантировать компетентность и завершить их обучение в сфере разработки документации. К навыкам в общении с людьми относятся:
<![if !supportLists]>· <![endif]>Межличностная коммуникация
<![if !supportLists]>· <![endif]>Навыки работы с группами
<![if !supportLists]>· <![endif]>Умение взаимодействовать с верхушкой руководства компании
<![if !supportLists]>· <![endif]>Умение обеспечить обратную связь
<![if !supportLists]>· <![endif]>Способность организовать команду, сформировать группы,быть хорошим слушателем
<![if !supportLists]>· <![endif]>Способность обучать других необходимым навыкам для работы, как с людьми, так и с техникой.
Технические навыки
Подыскивая сильного, чувствительного, решительного и творческого человека на роль руководителя проекта и специалиста по переобучению персонала, не забывайте также и о тех качествах, которыми разработчик документации должен обладать в ещё большей степени, чем навыками общения с людьми- тем более, если ему предстоит обучать других технической стороне дела. Он обязательно должен хорошо разбираться в соответствующем аппаратном и программном обеспечении, в сетевых платформах, а также уметь оценивать объём загрузки и необходимые действия по созданию средств автоматизации офиса.
В отсутствие грамотной системы технического контроля проекту будет недоставать технической согласованности. Он может рассыпаться на фрагменты из-за того, что каждый из сотрудников фирмы, занимающихся информационным менеджментом, пытается направить систему в нужное именно ему русло в соответствии со своими предрассудками. Что ещё более важно, компетентный в вопросах техники специалист по разработке документации сумеет провести команду через все препятствия на пути принятия технических решений, в то время как слабо знающий техническую сторону дела разработчик сам может подвергнуться неблагоприятному влиянию сотрудников,обладающих даром убеждения, но кроме этого ни в чём больше не разбирающихся.
К немаловажным навыкам относится умение определить сильные и слабые стороны среды клиент/сервер. Мне доводилось видеть системы с красиво оформленным интерфейсом, и при этом с таким низким быстродействием, что вполне можно было устроить перерыв на чашечку кофе, пока шёл процесс добавления документа в систему. Более того, потребуется стимулировать развитие навыков работы с СУБД и архитектурой хранилищ системы текстового поиска.
К техническим навыкам относятся:
<![if !supportLists]>· <![endif]>Понимание технической литературы
<![if !supportLists]>· <![endif]>Понимание научного и статистического подхода к сбору и анализу данных
<![if !supportLists]>· <![endif]>Достаточно обширный опыт работы с программным обеспечением для разработки документации, а также знание стандартов и спецификаций разработки документации
<![if !supportLists]>· <![endif]>Умение организовать и спланировать проект
<![if !supportLists]>· <![endif]>Опыт и познания в области информационного менеджмента и информационных технологий
<![if !supportLists]>· <![endif]>Хорошее знание большинства разновидностей офисной техники и особенностей операционных систем
<![if !supportLists]>· <![endif]>Понимание законодательной базы, регулирующей тайну и доступ к информации
<![if !supportLists]>· <![endif]>Знакомство с юридической стороной хранения документов в СУДФ и вывода их из обращения
Полномочия, ответственность и отчётность
До сих пор речь шла о многочисленных функциях, которые должен выполнять разработчик документации, и о той роли,которую он играет в процессе разработки. Картина, однако,будет неполной, если не принять во внимание другие не менее важные характеристики - полномочия, ответственность и отчётность.
Полномочия - это право и возможность влиять на исход предпринимаемых действий. Это право управлять, приказывать, решать, командовать и контролировать. Оно подразумевает и обязательность выполнения требований человека, облечённого властью. Право и власть в системах разработки документации базируется на уставе проекта и на предшествующей взаимосвязи разработчика документации с другими менеджерами и руководством организации. Уровень полномочий специалиста по разработке документации определяется его должностью в рамках проекта (менеджер, руководитель или консультант) объёмом власти, делегированным ему руководителем проекта со стороны фирмы. Когда полномочия базируются на рабочих функциях персонала, как только сотрудник принимает на себя обязательства по выполнению специального задания, полный спектр необходимых полномочий передаётся ему вместе с поручением от руководства проектом со стороны фирмы. По завершении работы над проектом разработчик документации лишается полномочий по управлению персоналом и снова начинает выполнять роль консультанта.
Когда система находится в стадии разработки, решения необходимо принимать быстро, исходя из всей имеющейся информации о проблеме или препятствии. Разработчик документации, который имеет обширный опыт в соответствующей области и принимает на себя обязательства по управлению командой и ресурсами, не должен оказаться жертвой постоянной борьбы за власть. Многочисленные приложения новой технологии, единожды продемонстрированные пользователям, тут же приобретают своих сторонников и обрастают теоретическими изысканиями. Тем не менее, информационный менеджмент и информационные технологии неоднократно доказывали, что каждая проблема имеет целый ряд потенциально правильных решений. Беспрестанный анализ, очевидно, приведёт к параличу всего начинания. Вместо того, чтобы то и дело анализировать альтернативные варианты, предприятию следует предоставить свободу действий разработчику документации,назначенному на должность менеджера проекта, чтобы он имел возможность внедрять методики, в успешности которых он не сомневается.
Под ответственностью понимается принятое кем-либо на себя обязательство выполнить или завершить определённое рабочее задание к утверждённой дате. Разработчику документации, назначенному на должность руководителя проекта, можно было бы поручить довести работу до очередной контрольной точки и уложиться при этом в оговоренный срок.
Назначение ответственного за выполнение работы подразумевает необходимость организации системы отчётности, то есть обязательства докладывать о порученном задании. Если разработчик документации принимает на себя обязательство выполнить определённое задание в соответствии с утверждённым графиком, но при этом он не обла дает достаточными полномочиями для руководства членами команды, которым можно поручить выполнение отдельных функций по заданию, то разработчик документации не может нести ответственность за успех всего начинания. Проект может ждать неудача даже в том случае, когда специалист по разработке документации с полной ответственностью подходит к выполнению отдельных частей задания. Конечно, разработчику документации не следует брать на себя ответственность за осуществление нереальных задач, но мир, в котором мы живём, далёк от идеала, и многие из нас стараются проявить себя как можно лучше и добиться как можно большего, насколько обстоятельства нам это позволяют.
Различные факторы могут повлиять на успех или провал начинания. Об отчётности можно судить по степени правдивости, с которой акционерам сообщают о результатах, достигнутых в процессе работы над РДФ, например, по следующим пунктам:
<![if !supportLists]>· <![endif]>Усовершенствование процесса управления документацией посредством утверждения его структуры и связанных с ним положений политики
<![if !supportLists]>· <![endif]>Достижение большей эффективности организации посредством внедрения системы управления документацией в оперативное и административное планирование
<![if !supportLists]>· <![endif]>Увеличение способности и подготовленности предприятия к решению стратегических и тактических задач, где решающую роль в достижении успеха может сыграть система управления документацией
<![if !supportLists]>· <![endif]>Активная поддержка нововведений и управление изменениями посредством разработки и внедрения новых руководств, методик, стандартов и спецификаций, а в результате и к улучшению корпоративной культуры.
В ходе окончательного анализа в соответствии с Вашими потребностями и структурой организации будет в точности определено, какую именно роль в проектировании СУДФ будет играть разработчик документации. Решение о том, чтобы назначить такого специалиста на должность руководителя проекта или консультанта во многом зависит от того, как организация намеревается взяться за осуществление проекта. Если компания не знакома с управлением документацией, она, возможно, предпочтёт нанять разработчика и поручить ему осуществление перевода фирмы на СУДФ. Однако, если в штате предприятия есть сильные, опытные менеджеры проектов, которые знают организацию, знают, как добиться выполнения задумок и способны принять на себя ответственность за результаты, компания может принять решение самостоятельно осуществить проект и нанять разработчика документации только для того, чтобы он предоставил необходимые консультации и провёл тренинг персонала, которому и будет поручено управление работой.
Распределение власти и ответственности
Я однажды столкнулся с ситуацией, когда персонал предприятия, занимавшийся вопросами информационных технологий,не был подготовлен к принятию единого протокола системы телекоммуникаций. Почти год у них ушёл на изучение сетевой архитектуры систем (SNA, Systems Network Architecture), Windows NT Sockets и Novell IPX/SPX, а также TCP/IP.
Параллельно шёл процесс отбора принципиально важного для организации механизма текстового поиска для выполнения отдельных исследовательских задач, а также была выбрана и приобретена СУДФ и система управления для библиотеки. Все три системы были выбраны предприятием, и в их основе лежал протокол TCP/IP, что давало возможность в полной мере использовать эффективность их работы.
Разработчик документации, руководивший проектом по отбору систем, изначально предполагал, что сотрудники с распростёртыми объятиями примут протокол TCP/IP, если рекомендованное программное обеспечение базируется на его платформе,благодаря чему обеспечивается действенная и эффективная коммуникация. Этот человек, однако, не обладал полномочиями самостоятельно принимать решение о внедрении этого протокола. В конечном итоге специалисты по информационным технологиям всё-таки согласились с тем, что протокол TCP/IP приемлемый (хотя и не лучший) вариант, на который предприятию следует согласиться. В результате внедрение системы затянулось как минимум на восемь месяцев, а заодно были упущены и многие возможности значительной экономии средств,изначально запланированные в ходе оценки окупаемости каждой программы. Никто не понёс ответственности за несостоявшееся увеличение производительности на ранних этапах внедрения СУДФ.
Запомните:
<![if !supportLists]>· <![endif]>ПУДФ должна быть согласованной и действовать во благо целей и миссии предприятия. Положения политики должны быть чётко и ясно изложены в письменном виде, и необходимо обеспечить доступ к этим записям в хранилище СУДФ.Механизм работы с направлениями политики фирмы должен включать в себя обратную связь, чтобы люди могли ознакомиться с политикой, задать вопросы и получить разъяснения.
<![if !supportLists]>· <![endif]>Кроме того, ПУДФ должна быть гибкой, чтобы своевременно реагировать на изменения в стандартах технологий и других условиях работы, но при этом не настолько гибкой, чтобы оказаться под влиянием слишком быстрых изменений,решения по которым лучше принимать на процедурном уровне. Право вносить коррективы в политику фирмы должно быть предоставлено только высшему руководству компании.
<![if !supportLists]>· <![endif]>При разработке политики компании следует принять во внимание следующие ключевые элементы: назначение, цель, определения, масштаб, правила проведения, ответственные лица, пересмотр и обновление. Все эти элементы в той или иной форме следует также отразить в письменном изложении направлений политики.
<![if !supportLists]>· <![endif]>Предприятию потребуется общая ПУДФ и связанные с ней варианты политики в отношении каждого аспекта управления документацией - отдельно для записей о сделках, для электронной почты, для уничтожения официальных записей и т.д.
<![if !supportLists]>· <![endif]>Потребуется участие в проектировании СУДФ специалиста по разработке документации, который может выступать в роли менеджера или руководителя проекта или консультанта. В должности менеджера проекта разработчик документации выполняет все функции, традиционно связанные с руководством проектом, но при этом основное внимание уделяет заданиям и достижениям, относящимся к проектированию документации. На позиции консультанта специалист по разработке выполняет разнообразную работу, начиная от непосредственного руководства и заканчивая консультациями для членов команды проектирования.
Запомните:
<![if !supportLists]>· <![endif]>Независимо от того, выступает ли специалист по разработке документации в роли менеджера, руководителя или консультанта, этому человеку необходимо обладать самыми разнообразными умениями в общении с людьми и в работе с техникой, чтобы добиться успеха в выбранной им сфере. Кроме того, разработчик документации должен быть облечён достаточной властью, чтобы его указания выполнялись, и принимать на себя ответственность за проделанную работу. Однако, вместе с тем, если специалист по разработке документации отвечает за успех или провал начинания, руководство предприятия должно гарантировать этому человеку, что никто не будет мешать ему в работе.
