Добрый день, меня зовут Сергей и я руководитель продуктового направления в компании «ДоксВижн». За время работы в сфере автоматизации электронного документооборота мне довелось участвовать в десятках проектов внедрения, причем в разных ролях (от инженера до руководителя проектного офиса), с разных сторон (заказчик, представитель компании-внедренца, вендор) и с разными системами (Docsvision и Directum). Своим проектным опытом я хочу поделиться с вами.
Зная процесс и набив кучу шишек, я даю в статье несколько рекомендаций, которые позволят подойти к проекту внедрения СЭД (как и любой ИТ-системы) подготовленными и более гладко его реализовать. Мой коллега уже давал советы ИТ-специалистам заказчика, ответственным за внедрение. Я взгляну на вопрос под другим углом и поделюсь рядом нюансов, которые стоит учесть именно компании-интегратору. Особенно, если вам предстоит первый проект внедрения. Надеюсь, статья будет полезна, хотя на многие «грабли» все равно нужно иногда наступать самостоятельно, и идеальных рецептов в проектной практике не существует.
А начнем мы не с проекта, начнем мы с того, что идет до проекта – обсуждение с клиентом деталей, подготовка предложения и заключение договора. Уже здесь есть многое, на что надо обратить внимание, т.к. это первый заложенный кирпичик, который потом может оказать влияние на устойчивость всего здания.
«А мне обещали…»
Одна из распространенных больших ошибок на этапе обсуждения проекта с клиентом, до заключения договора (особенно часто встречается у крупных интеграторов) — отсутствие Руководителя будущего проекта. Без него появляются какие-то договоренности (о которых он узнает, хорошо если не в конце проекта), разная трактовка задач и целей проекта и т.п. Когда это всплывает, заказчик начинает бить кулаками по столу и говорить, что ему обещали… Никаких обещаний может на самом деле и не быть, но если руководитель проекта при обсуждении отсутствовал, то понять, были эти договоренности или нет – он уже не сможет.
Команда молодости нашей
Еще один важный вопрос – формирование команды проекта. Не столько в плане подбора людей (это тоже важно, но здесь не об этом), сколько для представления команды заказчику и знакомства с его командой. Как правило, вполне достаточно представить команды заочно. Должен появиться документ, описывающий, кто и чем занимается с обеих сторон. Общая рекомендация: не стесняйтесь делать и подписывать разного рода бумажки с ответственными представителями заказчика, в какой-то момент это может вам очень сильно помочь.
План – это предмет простой…
Еще «на берегу» важно договориться о составе работ. Конечно, речь не о детальных требованиях к системе, а о верхнеуровневом списке проектных работ. В одном из проектов я столкнулся примерно с таким календарным планом:
У опытного человека, скорее всего, он вызовет только вопросы. Если не сразу, то потом, и вы начнете объяснять, почему трудоемкость работ 200 часов, в то время, как в команде проекта 1 человек, почему вы не будете проводить какую-то встречу с пользователями системы и т.п.
Никому эти трудоемкости не нужны, стоимость проекта уже известна, здесь эта информация лишь наводит на мысли…. План работ на этом этапе должен отражать максимально детальный состав работ (верхнеуровневый список) и основные этапы проекта с привязкой к датам, например, так:
Быстрее. Выше. Сильнее
Еще перед началом проекта нужно четко обговорить и зафиксировать цели и задачи, это может повлиять на всю дальнейшую работу. Например, ускорить процесс согласования договоров и сделать этот процесс прозрачным — это совершенно разные цели, а если цель просто «автоматизировать», то тут могут пониматься 100500 таких, как эти две. Неправильно поняв ожидания заказчика, вы можете серьезно промахнуться с оценкой всего проекта и, в конечном счете, он станет убыточным… хорошо еще, если при этом заказчик останется доволен. Обязательно детализируйте слишком общие цели, докапывайтесь до сути.
«А был ли мальчик?»
В самом начале нужно точно знать ответ на вопрос: «А есть ли, что автоматизировать?» Скорее всего, вы узнаете об этом сами, когда вам скажут: «Мы хотим внедрить СЭД, а заодно оптимизировать наши внутренние процессы». Часто слышали такое? Пока внутренние процессы не оптимизированы – вам там делать нечего, если, конечно, первым этапом проекта не является консалтинг. Недаром есть расхожее выражение «нельзя автоматизировать хаос» — автоматизация идет только следом за оптимизацией. Если заказчик хочет делать такие вещи параллельно, то это должно быть тревожным звоночком для вас, означающим, что нужно крайне внимательно подойти к процессу организации проекта. Сейчас, оглядываясь назад, я бы уже не стал ввязываться в такой проект, особенно если бы он был одним из моих первых.
«Однажды, в студеную зимнюю пору…»
…мы проводили интервью пользователей в крупной компании Y и зашли в кабинет департамента обеспечения безопасности… Вышли мы оттуда, собрав требования системы, а также с большими шансами на этом закончить проект. Представители службы безопасности выразили сомнения, что система, да и наша компания, соответствует их требованиям безопасности, и вообще заявили, что их никто не спросил.
К чему это я. Подумайте внимательно, кого может затронуть проект, заранее сходите к ним и обсудите все спорные вопросы. У меня в итоге все обошлось, вопрос разрешился, система соответствовала всем требованиям, и мы продолжили работу, но все могло быть хуже.
Кому все это нужно…
Часто приходится сталкиваться с тем, что большинство пользователей воспринимает вашу систему как что-то, навязанное им непонятно для чего. Поначалу я очень удивлялся этому, ведь раньше, внедряя системы бухгалтерского учета, никогда с этим не встречался (но и не удивительно, ведь для бухгалтеров система – основной рабочий инструмент, без него они в принципе не смогут работать). Казалось бы, что такого, а в итоге дело может закончиться саботажем.
Чтобы избежать подобных проблем, желательно заручиться поддержкой топ-менеджмента, или, как минимум, начало проекта должно сопровождаться выпуском приказа по компании, в котором будет указано, что и зачем внедряется, кто обязан участвовать в этом процессе и за что отвечать.
Здорово, если удастся провести какую-то агитационную работу, в ходе которой правильно донести цели и задачи проекта до конечных пользователей – пояснить им, что они получат в итоге, и зачем это им нужно. Сможете заручиться поддержкой хотя бы руководителей подразделений — количество проблем вы себе уменьшите.
Конечно, бывают случаи, когда ничего из этого невозможно, тогда все, на что вы можете рассчитывать – мастерство менеджера проекта. Как я уже говорил выше – не стесняйтесь подписывать бумажки, любое изменение должно быть согласовано и зафиксировано на бумаге, в тяжелую минуту это может спасти проект.
Как правило, внедрение СЭД начинается с этапа проектирования, на котором готовится и согласуется подробное техническое задание на будущую систему. Пожалуй, это наименее проблемный этап, ведь вы еще не заставляете заказчика работать с тем, что получилось, а вот когда этот момент настает — тогда проблемы и начинаются.
Связаны они, как правило, с тем, что заказчик видит результат либо на обучении, либо уже на этапе опытной эксплуатации, а иногда и вообще – при запуске системы в постоянную эксплуатацию. До этого все было только на бумаге, но буквы – это одно, а мегабайты – совсем другое.
О чем здесь стоит подумать?
Провести вводное обучение на начальной стадии проектирования системы. Показать ключевым пользователям, группе проекта (это пользователи, выступающие в качестве экспертов и формирующие состав требований к системе) систему, ее основные интерфейсы, возможности, базовые сценарии работы, возможности кастомизации.
Но этого недостаточно.
Больше интерфейса для пользователей. Описанная в предыдущем пункте практика для крупных внедрений может вообще не достигнуть своей цели. Правильным будет просто плотнее общаться с пользователями в процессе: Проводить небольшие демонстрации, показывая и обсуждая все наглядно и на «картинках», а не на «буквах», применять прототипирование (это позволяют системы с развитыми инструментами настройки интерфейсов, как, например, Docsvision, позволяющие создать интерфейс без какого-либо программирования), ну и, конечно, писать полноценное техническое задание.
Техническое задание: сделать подробные описания «для всех». В дополнение к вышеописанному есть еще одна рекомендация, касающаяся оформления ТЗ. Вещь, конечно, сугубо индивидуальная, каждый пишет по-своему, по принятым в компании стандартам и правилам, по ГОСТу и т.п., но важно не как, а что написано. Поскольку очень часто этот документ согласуют простые пользователи (делопроизводитель, например), то ошибкой может стать его написание на техническом языке. Описанные в таком документе настройки и конфигурации системы, может, и согласуют, но уж точно не понимая, что именно было согласовано. Есть практика явным образом выделить и описать 2 блока: первый — описание сценариев работы, т.е. кто, что и как будет делать в системе. Второй – уже описание настроек.
Думайте о том, кто и как будет в дальнейшем осуществлять поддержку системы. Чем больше используется стандартная функциональность выбранной платформы и ее штатные средства настройки, тем бОльшую часть всех настроек сможет поддерживать сам заказчик, тем дешевле и проще для него будет эта поддержка. Когда вас будут просить ту или иную доработку, донесите эту мысль, выяснив заодно, какой конкретно экономический эффект ожидает получить заказчик именно от этого дополнительного флажочка. Сопоставив две цифры, он, скорее всего, откажется.
Такое поведение, когда никто не хочет брать на себя ответственность за решения, свойственно немногим организациям, но встречается, и к этому надо быть готовыми. Зафиксируйте ЛПР со стороны заказчика в договоре, по возможности оговорите сроки согласования, это хоть немного дисциплинирует заказчика и минимизирует ваши риски на проекте.
После завершения работ по проектированию следует этап разработки системы. Здесь могу посоветовать только одно: не превращайте этот этап в «черный ящик». Мне приходилось работать с подрядчиками, которые считают, что вполне нормально после согласования технического задания уйти на месяц и появиться с готовой системой, чтобы уже обучать пользователей и запускать ее в опытную эксплуатацию. Чаще всего это заканчивается неудачей.
Честно говоря, поначалу я сам часто так делал, ну или почти так (мы все-таки делали одну предварительную демонстрацию в ходе работ).
Так мы и сделали, несмотря на то, что я сопротивлялся, ведь подобные работы не планировались и увеличивали стоимость проекта, уменьшая его рентабельность. Но я благодарен за этот совет — в итоге только благодаря этому и удалось сдать проект. С этим пользователем окончательно договориться о том, что ему нужно, мы так и не смогли, но зато заручились поддержкой всех остальных, включая генерального директора.
Здесь и раньше я в основном говорил о пользователях будущей системы, но не забывайте и об ИТ-специалистах заказчика – правильно построенные взаимоотношения с ними тоже сыграют немалую роль. Задумайтесь, какую роль они играют – они готовят железо для вашей системы, они обеспечивают работоспособность всей инфраструктуры, осуществляют техническую подготовку всех мероприятий вроде обучения или опытной эксплуатации, осуществляют поддержку пользователей и многое другое.
Наконец, все согласовано, настроено, сдано, пора проводить обучение и запускать систему в опытную эксплуатацию. Тут вы, скорее всего, столкнетесь с вопросом: на каких данных ее проводить – запускать и обрабатывать реальные документы или тестовые? Может быть, реальные, но параллельно вести их обработку в бумажном виде? Единственно правильного ответа нет, зато есть, над чем подумать.
Если выбрать тестовые документы, то пользователи будут относится к ним как к чему-то необязательному, как к чему-то, где нужно нажать кнопку, лишь бы отстали. К чему это приведет? Скорее всего, ни к чему хорошему, а к тому, что о том, что что-то не работает или работает не совсем так, вы узнаете после запуска в постоянную эксплуатацию. Последствия, думаю, понятны.
Если говорить о реальных документах, то предыдущей проблемы нет, но возможна ситуация, когда что-то пошло не так, повлияло на документооборот компании и привело к каким-то последствиям. По голове вас за это не погладят, поэтому при выборе такого варианта, нужно быть на чеку и, если что-то сбойнуло, моментально реагировать.
Вариант с параллельной обработкой документов в системе в тестовом режиме и на бумаге тоже имеет право на жизнь, но на него не все соглашаются, да и протестуют, как правило, конечные пользователи, поскольку им приходится делать двойную работу.
По мне так нужно выбирать какой-то промежуточный вариант: например, использовать реальные документы, но четко определить границы – ограничить виды документов, не запускать срочные и т.п. В любом случае, это то, о чем стоит подумать еще в начале и заранее договориться, как это будет организовано.
Что касается обучения пользователей, то весьма эффективным способом себя показал вариант, когда пользователи просто имитируют реальную работу в системе под собой, а не под абстрактными «учебными» пользователями, запуская процессы и проходя их полностью от начала до конца. При этом можно даже не давать никакой теоретической части или свести ее к минимуму. Пользователи могут как находиться в учебном классе, так и просто работать на своих местах. Последнее, правда, будет не очень удобно для преподавателя, поскольку ему придется бегать от пользователя к пользователю вслед за документом.
Такой способ не всегда подходит и не всегда может быть организован, но если получается, отдача будет, скорее всего выше, чем у других вариантов, попробуйте!
Можно еще долго говорить о том, с чем можно столкнуться. Я много шишек набил, всего и не упомнишь уже. Многое зависит от масштаба внедрения, от сферы деятельности организации и других факторов. Но главное не это и не платформа, которая внедряется (могу с уверенностью сказать, что среди тех, с которыми я сталкивался, каких-то существенных отличий в функциональности нет, но если бы мне сейчас предложили выбрать, что внедрить, я бы выбрал Docsvision), а правильно организованный процесс внедрения.
Интересно, кому с чем ещё приходилось сталкиваться, давайте расширим перечень и обменяемся опытом. Желаю всем удачи в проектах!
Зная процесс и набив кучу шишек, я даю в статье несколько рекомендаций, которые позволят подойти к проекту внедрения СЭД (как и любой ИТ-системы) подготовленными и более гладко его реализовать. Мой коллега уже давал советы ИТ-специалистам заказчика, ответственным за внедрение. Я взгляну на вопрос под другим углом и поделюсь рядом нюансов, которые стоит учесть именно компании-интегратору. Особенно, если вам предстоит первый проект внедрения. Надеюсь, статья будет полезна, хотя на многие «грабли» все равно нужно иногда наступать самостоятельно, и идеальных рецептов в проектной практике не существует.
На старт…
А начнем мы не с проекта, начнем мы с того, что идет до проекта – обсуждение с клиентом деталей, подготовка предложения и заключение договора. Уже здесь есть многое, на что надо обратить внимание, т.к. это первый заложенный кирпичик, который потом может оказать влияние на устойчивость всего здания.
«А мне обещали…»
Одна из распространенных больших ошибок на этапе обсуждения проекта с клиентом, до заключения договора (особенно часто встречается у крупных интеграторов) — отсутствие Руководителя будущего проекта. Без него появляются какие-то договоренности (о которых он узнает, хорошо если не в конце проекта), разная трактовка задач и целей проекта и т.п. Когда это всплывает, заказчик начинает бить кулаками по столу и говорить, что ему обещали… Никаких обещаний может на самом деле и не быть, но если руководитель проекта при обсуждении отсутствовал, то понять, были эти договоренности или нет – он уже не сможет.
У меня было несколько таких случаев. Один раз в крупной компании N, где я делал, по сути, пилотный проект на готовом коробочном решении, ИТ-директор вдруг решил, что поставим-то мы «коробку», но делать на ней будем большой кастомный проект, потому что именно об этом «договаривались». То, что цена на кастомную разработку в разы больше – его не смущало. В этом и подобных случаях, если не удавалось убедить заказчика своими силами (а часто так получалось), я просто устраивал очную ставку, приводя того, кто «договаривался». Главное – не давать слабину, и до последнего отстаивать свою позицию.
Команда молодости нашей
Еще один важный вопрос – формирование команды проекта. Не столько в плане подбора людей (это тоже важно, но здесь не об этом), сколько для представления команды заказчику и знакомства с его командой. Как правило, вполне достаточно представить команды заочно. Должен появиться документ, описывающий, кто и чем занимается с обеих сторон. Общая рекомендация: не стесняйтесь делать и подписывать разного рода бумажки с ответственными представителями заказчика, в какой-то момент это может вам очень сильно помочь.
План – это предмет простой…
Еще «на берегу» важно договориться о составе работ. Конечно, речь не о детальных требованиях к системе, а о верхнеуровневом списке проектных работ. В одном из проектов я столкнулся примерно с таким календарным планом:
У опытного человека, скорее всего, он вызовет только вопросы. Если не сразу, то потом, и вы начнете объяснять, почему трудоемкость работ 200 часов, в то время, как в команде проекта 1 человек, почему вы не будете проводить какую-то встречу с пользователями системы и т.п.
Никому эти трудоемкости не нужны, стоимость проекта уже известна, здесь эта информация лишь наводит на мысли…. План работ на этом этапе должен отражать максимально детальный состав работ (верхнеуровневый список) и основные этапы проекта с привязкой к датам, например, так:
Быстрее. Выше. Сильнее
Еще перед началом проекта нужно четко обговорить и зафиксировать цели и задачи, это может повлиять на всю дальнейшую работу. Например, ускорить процесс согласования договоров и сделать этот процесс прозрачным — это совершенно разные цели, а если цель просто «автоматизировать», то тут могут пониматься 100500 таких, как эти две. Неправильно поняв ожидания заказчика, вы можете серьезно промахнуться с оценкой всего проекта и, в конечном счете, он станет убыточным… хорошо еще, если при этом заказчик останется доволен. Обязательно детализируйте слишком общие цели, докапывайтесь до сути.
«А был ли мальчик?»
В самом начале нужно точно знать ответ на вопрос: «А есть ли, что автоматизировать?» Скорее всего, вы узнаете об этом сами, когда вам скажут: «Мы хотим внедрить СЭД, а заодно оптимизировать наши внутренние процессы». Часто слышали такое? Пока внутренние процессы не оптимизированы – вам там делать нечего, если, конечно, первым этапом проекта не является консалтинг. Недаром есть расхожее выражение «нельзя автоматизировать хаос» — автоматизация идет только следом за оптимизацией. Если заказчик хочет делать такие вещи параллельно, то это должно быть тревожным звоночком для вас, означающим, что нужно крайне внимательно подойти к процессу организации проекта. Сейчас, оглядываясь назад, я бы уже не стал ввязываться в такой проект, особенно если бы он был одним из моих первых.
У меня был один печальный опыт, связанный как раз с этим вопросом. Дело было в крупной компании Z и на старте проекта давалась установка, что нужно заодно оптимизировать процессы… При этом все сильно осложнялось отсутствием у заказчика лица, принимающего решения (это к вопросу о команде проекта и ответственности/обязанностях ее членов). Но подробнее об этом — позже.
«Однажды, в студеную зимнюю пору…»
…мы проводили интервью пользователей в крупной компании Y и зашли в кабинет департамента обеспечения безопасности… Вышли мы оттуда, собрав требования системы, а также с большими шансами на этом закончить проект. Представители службы безопасности выразили сомнения, что система, да и наша компания, соответствует их требованиям безопасности, и вообще заявили, что их никто не спросил.
К чему это я. Подумайте внимательно, кого может затронуть проект, заранее сходите к ним и обсудите все спорные вопросы. У меня в итоге все обошлось, вопрос разрешился, система соответствовала всем требованиям, и мы продолжили работу, но все могло быть хуже.
Кому все это нужно…
Часто приходится сталкиваться с тем, что большинство пользователей воспринимает вашу систему как что-то, навязанное им непонятно для чего. Поначалу я очень удивлялся этому, ведь раньше, внедряя системы бухгалтерского учета, никогда с этим не встречался (но и не удивительно, ведь для бухгалтеров система – основной рабочий инструмент, без него они в принципе не смогут работать). Казалось бы, что такого, а в итоге дело может закончиться саботажем.
Чтобы избежать подобных проблем, желательно заручиться поддержкой топ-менеджмента, или, как минимум, начало проекта должно сопровождаться выпуском приказа по компании, в котором будет указано, что и зачем внедряется, кто обязан участвовать в этом процессе и за что отвечать.
Здорово, если удастся провести какую-то агитационную работу, в ходе которой правильно донести цели и задачи проекта до конечных пользователей – пояснить им, что они получат в итоге, и зачем это им нужно. Сможете заручиться поддержкой хотя бы руководителей подразделений — количество проблем вы себе уменьшите.
Конечно, бывают случаи, когда ничего из этого невозможно, тогда все, на что вы можете рассчитывать – мастерство менеджера проекта. Как я уже говорил выше – не стесняйтесь подписывать бумажки, любое изменение должно быть согласовано и зафиксировано на бумаге, в тяжелую минуту это может спасти проект.
Начинаем…
Как правило, внедрение СЭД начинается с этапа проектирования, на котором готовится и согласуется подробное техническое задание на будущую систему. Пожалуй, это наименее проблемный этап, ведь вы еще не заставляете заказчика работать с тем, что получилось, а вот когда этот момент настает — тогда проблемы и начинаются.
Связаны они, как правило, с тем, что заказчик видит результат либо на обучении, либо уже на этапе опытной эксплуатации, а иногда и вообще – при запуске системы в постоянную эксплуатацию. До этого все было только на бумаге, но буквы – это одно, а мегабайты – совсем другое.
О чем здесь стоит подумать?
Провести вводное обучение на начальной стадии проектирования системы. Показать ключевым пользователям, группе проекта (это пользователи, выступающие в качестве экспертов и формирующие состав требований к системе) систему, ее основные интерфейсы, возможности, базовые сценарии работы, возможности кастомизации.
Но этого недостаточно.
В одном из проектов я столкнулся с тем, что подрядчик, сделав это, решил, что все теперь прекрасно знают продукт, и дальше процесс можно сильно упростить. В частности, все техническое задание представляло из себя описание изменений (настроек) относительно того, что было продемонстрировано. Я не рекомендую так делать, ведь проводя такое мероприятие, вы всего лишь (и то это зависит от качества проведения и людей) попытаетесь найти с пользователями общий язык, чтобы в дальнейшем понимать друг друга. Это не панацея, не стоит заблуждаться и думать, что спустя неделю кто-то из них что-то вспомнит.
Больше интерфейса для пользователей. Описанная в предыдущем пункте практика для крупных внедрений может вообще не достигнуть своей цели. Правильным будет просто плотнее общаться с пользователями в процессе: Проводить небольшие демонстрации, показывая и обсуждая все наглядно и на «картинках», а не на «буквах», применять прототипирование (это позволяют системы с развитыми инструментами настройки интерфейсов, как, например, Docsvision, позволяющие создать интерфейс без какого-либо программирования), ну и, конечно, писать полноценное техническое задание.
Техническое задание: сделать подробные описания «для всех». В дополнение к вышеописанному есть еще одна рекомендация, касающаяся оформления ТЗ. Вещь, конечно, сугубо индивидуальная, каждый пишет по-своему, по принятым в компании стандартам и правилам, по ГОСТу и т.п., но важно не как, а что написано. Поскольку очень часто этот документ согласуют простые пользователи (делопроизводитель, например), то ошибкой может стать его написание на техническом языке. Описанные в таком документе настройки и конфигурации системы, может, и согласуют, но уж точно не понимая, что именно было согласовано. Есть практика явным образом выделить и описать 2 блока: первый — описание сценариев работы, т.е. кто, что и как будет делать в системе. Второй – уже описание настроек.
Думайте о том, кто и как будет в дальнейшем осуществлять поддержку системы. Чем больше используется стандартная функциональность выбранной платформы и ее штатные средства настройки, тем бОльшую часть всех настроек сможет поддерживать сам заказчик, тем дешевле и проще для него будет эта поддержка. Когда вас будут просить ту или иную доработку, донесите эту мысль, выяснив заодно, какой конкретно экономический эффект ожидает получить заказчик именно от этого дополнительного флажочка. Сопоставив две цифры, он, скорее всего, откажется.
Как обещал выше, расскажу, что может случиться на этом этапе, если заказчик одновременно с внедрением захочет оптимизировать свои внутренние процессы. Итак, крупная компания X, внедряем СЭД, а заодно переделываем внутренние процессы, которые затрагивают почти все подразделения. Сразу скажу, что этот проект собрал большую часть «неправильного», на мой взгляд, поведения подрядчика, о котором я пишу в этой статье, но решающим стало другое. Была сформирована рабочая группа проекта, назначены ответственные, и даже выпущен приказ по компании, но в этой рабочей группе не хватало одного – лица, принимающего решения. Точнее, формально он был, но в силу высокой занятости далеко не всегда присутствовал на бесконечных встречах, посвященных требованиям к системе, а это казалось действительно бесконечным: мы мусолили одни и те же вопросы по много раз, на ходу придумывались способы все упростить, а иногда, наоборот, усложнить, но как только нужно было что-то утвердить, все умывали руки. Мы пытались сформулировать тезисно, о чем договорились, и согласовать это, но, когда это превращалось в техническое задание или собиралось совещание для обсуждения связанных процессов, все опять могло в корне поменяться.Дам возможность каждому подумать, что можно было бы сделать в этой ситуации.
Чтобы хоть как-то остановить этот процесс, я бегал за тем самым ЛПР, пытаясь это решение получить или вызвать его на очередное совещание. Это помогло, конечно, но оказалось не самым быстрым вариантом, все сильно растянулось. Затевать официальную переписку между подрядчиком и компанией я не стал, поскольку все проходило в довольно дружественной обстановке и никаких санкций не предвиделось, в то время как обратное могло повлечь за собой ухудшение отношений.
Такое поведение, когда никто не хочет брать на себя ответственность за решения, свойственно немногим организациям, но встречается, и к этому надо быть готовыми. Зафиксируйте ЛПР со стороны заказчика в договоре, по возможности оговорите сроки согласования, это хоть немного дисциплинирует заказчика и минимизирует ваши риски на проекте.
Где-то на середине пути…
После завершения работ по проектированию следует этап разработки системы. Здесь могу посоветовать только одно: не превращайте этот этап в «черный ящик». Мне приходилось работать с подрядчиками, которые считают, что вполне нормально после согласования технического задания уйти на месяц и появиться с готовой системой, чтобы уже обучать пользователей и запускать ее в опытную эксплуатацию. Чаще всего это заканчивается неудачей.
Честно говоря, поначалу я сам часто так делал, ну или почти так (мы все-таки делали одну предварительную демонстрацию в ходе работ).
Однажды в крупной компании Z я столкнулся с пользователем, который хотел, чтобы СЭД сама расписывала за него поручения и т.п., чуть ли не в магазин за хлебом она должна была бегать по его желанию. В ходе проведения интервью мы объясняли, о чем-то договаривались, что и как будет работать, но когда он согласовывал документ, опять появлялись вопросы. Сотрудник этот занимал достаточно высокую должность и мог оказывать сильное влияние на проект.Глядя на то, что происходит, ИТ-директор этой компании дал один простой совет. Это даже не совет был, он настаивал: нужно чаще встречаться с пользователями, обсуждать, убеждаться в том, что все одинаково понимают, проводить демонстрации, пользователи должны нас знать, чтобы если кого-то спросить, кто вам внедряет СЭД, каждый сказал: «Да бегает тут один. Сергеем звать.»
Так мы и сделали, несмотря на то, что я сопротивлялся, ведь подобные работы не планировались и увеличивали стоимость проекта, уменьшая его рентабельность. Но я благодарен за этот совет — в итоге только благодаря этому и удалось сдать проект. С этим пользователем окончательно договориться о том, что ему нужно, мы так и не смогли, но зато заручились поддержкой всех остальных, включая генерального директора.
Здесь и раньше я в основном говорил о пользователях будущей системы, но не забывайте и об ИТ-специалистах заказчика – правильно построенные взаимоотношения с ними тоже сыграют немалую роль. Задумайтесь, какую роль они играют – они готовят железо для вашей системы, они обеспечивают работоспособность всей инфраструктуры, осуществляют техническую подготовку всех мероприятий вроде обучения или опытной эксплуатации, осуществляют поддержку пользователей и многое другое.
Мы строили, строили…
Наконец, все согласовано, настроено, сдано, пора проводить обучение и запускать систему в опытную эксплуатацию. Тут вы, скорее всего, столкнетесь с вопросом: на каких данных ее проводить – запускать и обрабатывать реальные документы или тестовые? Может быть, реальные, но параллельно вести их обработку в бумажном виде? Единственно правильного ответа нет, зато есть, над чем подумать.
Если выбрать тестовые документы, то пользователи будут относится к ним как к чему-то необязательному, как к чему-то, где нужно нажать кнопку, лишь бы отстали. К чему это приведет? Скорее всего, ни к чему хорошему, а к тому, что о том, что что-то не работает или работает не совсем так, вы узнаете после запуска в постоянную эксплуатацию. Последствия, думаю, понятны.
Если говорить о реальных документах, то предыдущей проблемы нет, но возможна ситуация, когда что-то пошло не так, повлияло на документооборот компании и привело к каким-то последствиям. По голове вас за это не погладят, поэтому при выборе такого варианта, нужно быть на чеку и, если что-то сбойнуло, моментально реагировать.
Вариант с параллельной обработкой документов в системе в тестовом режиме и на бумаге тоже имеет право на жизнь, но на него не все соглашаются, да и протестуют, как правило, конечные пользователи, поскольку им приходится делать двойную работу.
По мне так нужно выбирать какой-то промежуточный вариант: например, использовать реальные документы, но четко определить границы – ограничить виды документов, не запускать срочные и т.п. В любом случае, это то, о чем стоит подумать еще в начале и заранее договориться, как это будет организовано.
Что касается обучения пользователей, то весьма эффективным способом себя показал вариант, когда пользователи просто имитируют реальную работу в системе под собой, а не под абстрактными «учебными» пользователями, запуская процессы и проходя их полностью от начала до конца. При этом можно даже не давать никакой теоретической части или свести ее к минимуму. Пользователи могут как находиться в учебном классе, так и просто работать на своих местах. Последнее, правда, будет не очень удобно для преподавателя, поскольку ему придется бегать от пользователя к пользователю вслед за документом.
Такой способ не всегда подходит и не всегда может быть организован, но если получается, отдача будет, скорее всего выше, чем у других вариантов, попробуйте!
Можно еще долго говорить о том, с чем можно столкнуться. Я много шишек набил, всего и не упомнишь уже. Многое зависит от масштаба внедрения, от сферы деятельности организации и других факторов. Но главное не это и не платформа, которая внедряется (могу с уверенностью сказать, что среди тех, с которыми я сталкивался, каких-то существенных отличий в функциональности нет, но если бы мне сейчас предложили выбрать, что внедрить, я бы выбрал Docsvision), а правильно организованный процесс внедрения.
Интересно, кому с чем ещё приходилось сталкиваться, давайте расширим перечень и обменяемся опытом. Желаю всем удачи в проектах!
