Не хотел переходить к процессам, пока не закончим с ProjectLibre, RedMine-ом и финансовой программой. Однако тут необходимо сделать некоторые отступления от плана.
Вот у меня был сделан и опубликован кейс по использованию ProjectLibre при планировании проекта внедрения ИС. Однако кейс хоть и был приближенным к реальности, но он основывался на обобщенной модели процессов внедрения ИС. К слову сказать, таких моделей несколько. Мы рассмотрели одну, чуть позже я опубликую статью по оптимизации, в которой мы перейдем к другой модели. А так как минимум есть следующие модели внедрения (названия даны исключительно для себя):
- пять этапов с подготовкой к опытной эксплуатации (ее, собственно, рассмотрели в перечисленных выше 6 статьях);
- пять этапов с обучением (к ней перейдем в процессе оптимизации проекта);
- четыре этапа (соответственно, в ней вся «техническая» подготовка ИС и документация уходит во второй этап, а обучение - в самое начало четвертого).
Кроме того есть целая уйма «вырожденных» вариантов. Кроме того, есть варианты, когда проект не является самостоятельной сущностью, а реализуется в рамках программы проектов. Либо наоборот, вместо программы проектов организован единый проект, но с очередями внедрения.
В общем вариантов полно, отмечу лишь, что в рамках публикаций был рассмотрен весьма заурядный проект. И если вы «поплыли» от изложенных объемов информации, то есть повод поискать и почитать информацию о том, а как же реализуются сложные проекты.
Прежде чем переходить к оптимизации решил сделать дополнительную статью, в которой обобщу вопросы, которые следует детализировать для составления плана. Напомню, что технически составить план - недолго. А вот получить информацию для его корректного составления - это целая эпопея. Также напомню, что подобный план ценен не сам по себе. На основании его нам нужно будет впоследствии сделать много чего - это и КП, это и расчет финансов проекта, это план управления рисками, и много чего еще... Тот же план привлечения ресурсов - ведь у нас одного из аналитиков в кейсе планируется привлечь на субподряд. Но может так статься, что продавец согласует с заказчиком дату старта не 01.02 (дата, от которой мы ведем план), а, скажем, 01.04. И тогда у нас будет время, например, чтобы нанять сотрудника.
Но перейдем к уже к получению информации, необходимой для планирования. Сначала - общий перечень групп:
- по прикладным областям;
- по интеграции;
- по загрузке первоначальных данных;
- по инфраструктуре;
- по обучению;
- по документации;
- по привлечению сотрудников заказчика к проекту.
Итак, теперь подробнее.
Получение информации по прикладным областям
Здесь наши цели:
- получить перечень согласованных бизнес-функций к автоматизации;
- прикинуть что из этого покрывается внедряемой ИС, где будут доработки, а где - разработка бизнес-логики с нуля;
- сделать грубую предварительную оценку по затратам на разработку.
Соответственно, здесь сначала нужно начать с перечня прикладных областей. Да, разумеется, мы на входе проинформированы в общем и целом о том, что предполагается автоматизировать. И, само-собой, нет никаких «Прикладных областей_1», «прикладных областей_2», «прикладных областей_3» и «прикладных областей_4». Но вот к примеру, если мне скажут надо автоматизировать прикладную область «Логистика», то я могу предположить целую кучу различных вариантов, причем только на самом верхнем уровне (закупки, перевозки, складской учет, таможенное оформление, внутрискладское перемещение, межскладское перемещение, доставка товара и т.д.), а еще могут быть комбинированные варианты. Или прикладная область «Продажи». Сюда могут запросто отнести и маркетинг. Вот, к пример, программа лояльности относится ли к продажам? С одной стороны - да, а с другой стороны - это маркетинговый инструмент, направленный на увеличение продаж. Но с тем же успехом можно и закупки причислить к продажам - не закупите товар, нечего будет выставить на полку, а значит и покупатель не будет иметь шансов сделать покупку, а вы, соответственно, продажу. Но наша задача - не притягивать кота за рога, а наоборот - четко понять, что конкретный заказчик понимает под конкретной прикладной областью.
А вот после того, как вы разобрались с самым верхним уровнем, начинается самое интересное. Я бы сформулировал задачу так. Нужно, не являясь сотрудником компании, который видит тот или иной процесс в целом (а это руководители или старшие специалисты по тем или иным направлениям), понять, какие бизнес-функции нужно автоматизировать. С одной стороны звучит как парадокс, но это только на первый взгляд.
Для решения данной задачи у нас есть следующие инструменты:
- знания типовых процессов по прикладной области;
- знания отраслевых процессов по прикладной области;
- личный опыт внедрения ИС в аналогичные компании;
- опыт внедрения ИС организации в аналогичные компании;
- знания соответствующего контура (или модуля) внедряемой ИС;
- настроенный для показа стенд с развернутой ИС.
То есть вначале нужно составить перечень вопросов по прикладным областям, базируясь на первых 4 пунктах. Логично, что к этим работам нужно привлечь аналитиков по соответствующей прикладной области.
То есть да, по деталям процессов конкретной организации у нас нет и не может быть знаний. Однако ничто (кроме отсутствия соответствующих компетенций) не может помешать нам составить перечень вопросов по схожим процессам и уточнить, так оно или не так.
После составления данные списки направляются соответствующему представителю заказчика и назначаются встречи. Соответственно, чтобы они проходили более продуктивно, должен быть настроен стенд. Понятное дело, что это будет не настроенная и готовая к передаче система. Но при обсуждении вопросов по автоматизации очень помогает, когда помимо «схематичных» вопросов есть возможность показать как примерно система хранит ту или иную информацию, как отражает те или иные операции, как формирует те или иные отчеты и т.д.
Соответственно, после проведения серии встреч у нас должна сформироваться общая картина по автоматизации прикладных областей, которую можно оформить в виде электронной таблицы со следующими полями:
- прикладная область;
- бизнес-функция;
- тип изменений в системе (отсутствует, частичные доработки, разработка);
- описание сути изменений (тут кратко, допустим, добавить поле «такое-то», добавить закладку в справочник, содержащую «такую-то» информацию, разработать справочник для хранения «такой-то» информации, добавить шаг «такой-то» в «такой-то» операции, добавить такие-то сведения в такую-то операцию и т.д. и т.п.).
Соответственно, у нас в данный момент времени не стоит задачи детального обследования, но общую картину получить надо, также надо прикинуть приблизительный объем разработки.
Поэтому после получения обобщенной информации об автоматизируемых бизнес-функциях данную информацию надо проанализировать и оценить по затратам на разработку. Возможно, после проведенного анализа потребуется составить и обсудить ряд дополнительных вопросов.
Однако формировать пул участников проекта еще рано. Хотя на основании полученных данных уже можно понять, какими компетенциями должен обладать пул аналитиков проекта. А вот с разработчиками, тестировщиками - пока еще рано. Поскольку разработка может быть не только по функциональным разрывам, но и по механизмам интеграции, а также по механизмам импорта первоначальных данных. Хотя в нашем кейсе последнее отсутствует, поскольку для упрощения кейса мы приняли вводные данные, что загрузка первоначальных данных будет осуществляться исключительно стандартными механизмами, в реальных проектах такая разработка может потребоваться.
Таким образом в завершении данной предпроектной активности у нас должна быть информация, желательно оформленная в виде электронной таблицы:
- прикладная область;
- бизнес-функция;
- тип изменений в системе (отсутствует, частичные доработки, разработка);
- описание сути изменений (если они есть, естественно);
- затраты разработчика.
Получение информации по интеграции
Следующая информация, которую нам нужно получить - прогнозируемые объемы работ по интеграции информационных систем.
Опять же начинаем с самого общего - перечня ИС, с которыми нужно интегрировать внедряемую систему. Скорее всего вы будете замещать ранее внедренную ИС, поэтому самый простой способ - это узнать, а с какими ИС интегрирована замещаемая система. Однако данный способ не универсален в виду того, что:
- во-первых, вы все же имеете шанс столкнуть именно с первичным внедрением;
- во-вторых, возможно у заказчика были планы по интеграции замещаемой ИС, но в виду предстоящего внедрения новой системы он их отложил и хочет реализовать в ходе внедрения;
- в третьих, не исключен вариант разделения ИС, то есть у заказчика была одна «большая» ИС, а он хочет ее разделить на несколько, таким образом, что по завершению проекта замещаемая ИС будет выведена из эксплуатации не полностью, а лишь по внедряемым контурам новой системы, а со старой нужно будет интегрироваться.
То есть ситуации могут быть разные. Поэтому желательно ознакомиться с полным списком информационных систем и общими сведениями по тому, какую область они автоматизируют. А нужно это хотя бы для того, чтобы в процессе работ по реализации проекта внезапно, как крокодил из будки, не всплыла необходимость интегрироваться с незапланированной ИС. Да, заказчик может сказать «ребята, не лезьте, вот сказано - с такими системами надо интегрироваться, вот по ним и задавайте вопросы». В этом случае, конечно, не надо лезть на рожон, спокойно фиксируем в проекте договора фразу «...с прочими информационными системами интеграция не предусмотрена». Тем самым избегаем и конфликта на стадии предпроекта, и конфликта на стадии реализации проекта (если все же выяснится, что все же интеграция была нужна). Ну а если уж выяснится, что делать интеграцию с еще одной системой все же нужно - ну тут будет явное расширение проекта.
Соответственно, после того, как определились с перечнем ИС, нужно крупными штрихами, не опускаясь в детали понять какие данные, по какому типу событий в какую ИС направляются (или наоборот из какой системы получаются).
Помимо этого, нам нужно понимать, какие механизмы интеграции использовались ранее и предполагается ли их дальнейшее использование или нет. И здесь нас тоже может поджидать засада (если мы не проявим должной решительности и наблюдательности). Например, в текущей ситуации у заказчика передача данных может осуществляться раз в сутки, а он хочет, чтобы данные передавались «онлайн». И вот это слово «онлайн» в договоре может и сорвать сроки проекта, и просадить маржинальность (если у нас «внешний» проект). Я уж не говорю, о такой прелести как «внезапная необходимость в компетенциях», когда выясняется, что для внедрения новой системы интеграции в следующем месяце будет требоваться редкий высокооплачиваемый специалист, со среднем сроком найма два-три месяца. А все потому, что данный вопрос не был рассмотрен и оговорен на предпроектной подготовке. Я же отмечу, что организация передачи данных онлайн (особенно при большой нагрузке) это внедрение отдельной технической информационной системы. А ведь еще заказчик может пожелать «склейку» данных. Вполне понятное и нормальное пожелание. Беда в том, что если РП пропустит данное выражение в договоре без должного внимания, он уже на стадии продажи, скорее всего, завалит проект. Поскольку (особенно если заказчик «большой» и у него много ИС) реализация только одного этого пожелания - это отдельный и не маленький проект.
Поэтому хоть активность по получения предварительных данных по интеграции менее трудозатратное мероприятие, чем получение предварительных данных по прикладным областям, но именно здесь РП может «профукать» (если не сказать по-другому) проект, даже не приступая к его реализации. Поэтому к системной интеграции нужно отнестись очень внимательно, подробно обсуждать пожелания заказчика, подробно рассказывать заказчику в какую сумму (или в какие затраты, если мы говорим о внутреннем проекте) выльется заказчику слово «онлайн», «склейка данных» и т.д. Уточнять, а действительно ли есть такая необходимость.
В итоге нам нужно получить следующую информацию (крайне желательно, оформленную в виде эле тронной таблицы):
- ИС-источник;
- ИС назначения;
- что передаем (краткое описание данных, не заглубляясь в детали)
- нужна ли обработка данных (опять же без подробностей);
- событие передачи (триггер, периодические);
- способ передачи (файл, запрос в БД, запрос по API и т.д. - если используются разные способы).
Соответственно, для получения данной информации нужно общаться со специалистами, поддерживающими текущие ИС заказчика. После получения информации и приведения ее к выше описанному виду следует привлечь специалиста, который может оценить по неполным данным время на разработку и настройку интеграции. Обращаю внимание на словосочетание «оценить по неполным данным», поскольку если вы поставите такую задачу программисту, который работает по ТЗ, вы получите ответ а-ля «у меня нет достаточных данных для того, чтобы сказать сколько это займет». То есть обращаться надо к сотруднику, который «живет» именно на стыке разработки и бизнес-процессов. Это может быть технический архитектор или системный аналитик со специализацией именно в интеграции информационных систем.
В результате в нашем файлике должно появиться 2 заполненных поля:
- разработка;
- настройка.
По интеграции информационных систем будет впоследствии отдельная ветка. Тема большая и интересная. Но скорее всего уже осенью, так как сейчас надо сначала описать все основы (а все что я описываю сейчас - это именно основы, которые знает любой РП, поучаствовавший хотя бы в паре-тройке проектов), а только затем переходить к другим темам.
Получение информации по загрузке первоначальных данных
Напомню, здесь в нашем кейсе мы установили ограничения:
- перегружаются только справочники;
- используются только стандартные механизмы ИС.
В реальных проектах может быть все намного сложнее:
- во-первых, может возникнуть необходимость загрузить не только справочные данные но и операции;
- во-вторых, может возникнуть необходимость не просто перегрузить данные, а свернуть их по определенным аналитикам;
- в-третьих, может возникнуть необходимость разработать механизмы загрузки первоначальных данных.
Итак, здесь надо первым делом определить, какие именно данные будем перегружать:
- только справочники;
- операции;
- трансформированные операции.
Соответственно, это 3 разных уровня сложности и объема трудозатрат. То есть если при перегрузке справочников, как правило, достаточно в качестве хранилища иметь выделенное место под электронные таблицы, то при перегрузке операций может статься, что придется использовать базу данных. Тут, конечно, все зависит от объема записей в объектах. Однако вряд ли можно найти справочники с количеством записей более миллиона, а вот для операций миллионы и даже миллиарды строк - это нормальная ситуация.
Во-вторых, нам предстоит как минимум дважды загружать первоначальные данные. И если в справочники информация добавляется довольно редко, и может так статься, что за время, прошедшее с конца 3-го этапа до середины 5-го, в какие-то справочники новых данных вовсе не поступит, а в какие-то пару-тройку записей, которые можно внести во внедряемую систему и вручную, то в объекты операций за это время добавится множество новых строк и поэтому их придется именно догружать.
В-третьих, при трансформации данных может возникнуть необходимость по части периодов не догружать данные, а сначала повторно трансформировать и только затем догружать.
В отношении механизмов загрузки:
- их может вообще не быть в стандарте (или не быть для части объектов) и тогда даже для загрузки справочников нам придется либо разрабатывать механизмы загрузки, либо грузить непосредственно в БД;
- они могут быть неудобными для того объема данных, который требуется перегрузить, особенно если это касается не простой загрузки, а загрузки с предварительной трансформацией.
Поэтому тут тоже может потребоваться разработка. При этом, если у нас есть стандартные механизмы загрузки нам придется обосновать, зачем при их наличии нам требуется таковая разработка. А для этого нам надо будет прикинуть и сравнить объем трудозатрат при загрузке с трудозатратами с использованием стандартных механизмов с разработкой специализированных механизмов плюс затраты на саму загрузку. Соответственно, что окажется дешевле, то и выбирать.
Что нужно перегружать в новую систему вам сможет подсказать владелец процесса, также он сможет подсказать в каком он виде хочет иметь данные в новой ИС. В свернутом или «1:1». По объемам загрузки можно уточнить у службы, осуществляющей поддержку. То есть нам тут не нужно знать конкретику по данным, а просто «справочник «Такой-то» - 200 записей, справочник «Второй» - 500 записей, Документ или Журнал «Третий» - 10005000 записей». Ну и соответственно в результате данной активности для составления плана нам нужна следующая информация:
- тип объекта ИС;
- название объекта ИС;
- объем хранимых данных;
- требуется трансформация (да, нет);
- краткое описание трансформации (опять же не надо заходить в детали - у нас для этого будет первый этап проекта).
Исходя из возможностей внедряемой системы, объема и способа переноса данных, определяем нужно ли писать механизмы загрузки. Если нужно, добавляем поле трудозатраты на разработку и отдаем техническому архитектору или системному аналитику на оценку объема разработки. В итоге здесь добавляется еще одна графа «Объем разработки».
Получение информации по инфраструктуре
Здесь тоже довольно много уточнений надо сделать в ходе предпроектной подготовки. У нас по кейсу было определено:
- серверы - «железные»;
- размещение - в серверной заказчика;
- требуется поставка железа для сервера приложений и СУБД;
- требуется установка операционных систем на поставляемые серверы, а также ПО для СУБД.
На самом деле в реальных проектах в данном аспекте все может быть как намного интереснее, так и намного скучнее.
Начнем с того, что поставки и работ по развертыванию может и не быть вовсе. Все ограничится только составлением технической спецификации и передачи ее заказчику. А дальше он сам своими силами развертывает площадки, а нам предоставляет доступ уже к развернутым площадкам. При этом это может быть как «железные» серверы, так и виртуальные. На самом деле нас это будет мало касаться при таком варианте событий.
Может быть как описано в кейсе - поставка «железных» серверов и развертывание в серверной заказчика.
Следующий вариант - поставка мощного сервера с его последующей виртуализацией и «нарезкой» серверов для проекта. Здесь у нас относительно кейса возникают дополнительные затраты на ПО для виртуализации, плюс трудозатраты на установку такого ПО, плюс на «нарезку» виртуальных серверов
Следующий вариант - поставка «железных» серверов, но размещение не на площадке заказчика, а в ЦОДе. Здесь возникают дополнительные затраты на подготовку договоров на размещение, а также на подготовку документации на размещение (само-собой, никто не пустит вас в ЦОД самостоятельно что-то монтировать).
Следующий вариант - аренда виртуальных серверов в ЦОДе. Тут дополнительные трудозатраты относительно указанных в кейсе примерно аналогичны предыдущему пункту.
Само-собой, первое, что нужно уточнить - будем ли что-то делать по серверному оборудованию и если да, то что конкретно. Основные варианты изложил выше.
Далее. У нас в кейсе 1 роль - 1 сервер. Однако на деле может возникнуть необходимость развертывание кластеров серверов для промышленной площадки (само-собой, на тестовую так тратиться вряд ли кто-то будет). Опять же кластер - это минимум 2 сервера. Под каждый сервер нужна ОС. Под СУБД нужно кластерное ПО. Поэтому тут идет увеличение затрат и на лицензии, и на развертывание ОС.
Кроме того в нашем кейсе мы используем систему резервного копирования заказчика. Однако, у заказчика может не быть таковой (например все резервируется внутренними механизмами). А кроме того, может не быть места в хранилищах резервных копий. И тогда, возможно придется решать данный вопрос.
Соответственно, нужно выяснить, что с системой резервного копирования и кто будет ее настраивать. Тут тоже могут появиться дополнительные трудозатраты.
Опять же относительно администрирование серверов. Может так статься, что у заказчика сеть построена на базе одной операционной системы, а он задумал переход на другую. Соответственно, наши сервера уже должны быть построены на базе новой ОС, однако у заказчика пока нет специалистов для ее администрирования. То есть тут возможна необходимость как услуг по администрированию серверов на новой ОС (пока не появятся соответствующие специалисты в штате), так и услуги по обучению штатных сотрудников администрированию новой ОС. А возможен и гибридный вариант, например, обучение и администрирование, пока штатные сотрудники наберутся практики по работе с новой ОС. В общем тут также возможны варианты взаимодействия и этот момент надо также уточнять.
Плюс ко всему, нам нужно составить спецификацию на сами серверы. Соответственно для этого нам надо уточнить предполагаемое количество пользователей. А также планы на рост в течение 5 лет. Понятно, что в настоящее время такие пертурбации, что и не понятно, что будет в следующем квартале по факту, однако вряд ли кто-то специально планирует падать, поэтому лучше заложиться на «железное» железо с учетом планов. С виртуальными ресурсами в данном плане чуть проще - их можно увеличить, а железо под виртуализацию - докупить.
Соответственно исходя из общего количества пользователей (одновременное количество пользователей традиционно берем как треть от общего) и рекомендаций вендора составляем спецификацию на конфигурацию серверов и каналов.
Соответственно ожидаемый результат - краткое описание из тех вариантов, что я перечислил выше.
Получение информации по обучению
В нашем кейсе обучение представлено по-максимуму:
- обучение группы проведения опытной эксплуатации;
- обучение всех прочих пользователей, не входящих в группу ОЭ;
- обучение технического персонала.
Однако зачастую заказчик экономит, заказывает обучение группы ОЭ и тех.персонала, а обучение остальных пользователей проводит силами группы ОЭ.
В рамках данной активности важно выяснить, кого конкретно надо будет учить, сколько человек, должности и приблизительно какой объем работ у каждой группы должностей будет в системе.
Опять же, не стоит зарываться в подробности проведения тех или иных операций. Нам нужно просто приблизительно понять, сколько групп нужно будет сформировать. И исходя из этого мы сможем спрогнозировать трудозатраты и составить план.
Напомню, в нашем кейсе обучаются:
- группа ОЭ - на этапе 3 «Подготовка к проведению ОЭ» строго до старта опытной эксплуатации;
- все прочие пользователи - на этапе 4 «Опытная эксплуатация»;
- технический персонал - на этапе 5 «Перевод в промышленную эксплуатацию» в рамках активности по организации сопровождения.
Собственно уточняем объемы обучения, прикидываем предварительно трудозатраты, озвучиваем приблизительную стоимость.
Соответственно, обучение группы ОЭ - минимум. Остальное - опционально.
Получение информации по документации
Еще одна интересная тема. Категорически против утверждения, что «результат важнее документации». В свое время писал длинный пост по этому поводу, здесь повторяться не буду, но приведу ссылку на этот пост (ссылка на пост).
Суть в том, что это какая-то подмена понятий, ибо документация - это и есть часть результата проекта. Ну а как-то противопоставлять, спрашивая, что важнее ухо или палец считаю крайне глупым.
А вот излишней документации (то есть документации ради документации) в проекте быть не должно. Ну точнее как... Если заказчик требует по каким-либо причинам дублирующую документацию, то отказываться только на основании этого от проекта, думаю, не имеет смысла. Надо - так надо, но:
- не предлагать такого на пресейле;
- если заказчик требует такую документацию, то следует подсказать, где будет содержаться дублирующая информация
Ну а там дальше - по его решению. В целом же каждый документ должен иметь определенное назначение.
В нашем кейсе предусмотрена следующая документация:
1. Для этапа 1 «Обследование и анализ»:
- отчет о проведении обследования;
- частное техническое задание (ЧТЗ);
- описание архитектуры;
- пояснительная записка к техническому проекту.
2. Для этапа 2 «Разработка и настройка»:
- отчет о проведении разработки;
- программа и методика предварительных испытаний.
3. Для этапа 3 «Подготовка к проведению опытной эксплуатации»:
- инструкция администратора;
- инструкция пользователя;
- программа обучения пользователей;
- программа и методика проведения опытной эксплуатации.
4. Для этапа 4 «Опытная эксплуатация»:
- программа и методика приемочных испытаний;
- отчет о проведении опытной эксплуатации.
5. Для этапа 5 - отчет о проведении приемочных испытаний.
Соответственно, заказчику нужно кратко рассказать про каждый документ, зачем он нужен. Также важно заранее подготовить шаблоны документации и передать для согласования.
У заказчика может быть свой набор документов. Их надо проанализировать, иногда случается так, что документы одни и те же (по сравнению с предложенными заказчику), но разнятся по названиям.
По документации также сделаю серию публикаций. Частично описал в постах, но не все и только в «двух словах». В публикациях же подробно разберу «что, для чего и зачем».
Итогом же данной активности на пресейле должен быть предварительно согласованный список документации, разбитый по этапам.
Получение информации по привлечению сотрудников заказчика к проекту
Этот вопрос можно рассматривать в 2 аспектах:
- во-первых, привлечение сотрудников как источник информации (на этапе 1 «Обследование и анализ» - интервьюируемые по бизнес-процессам), для оценки предварительных результатов (на этапе 2 «Разработка и настройка» - промежуточные показы разработанной функциональности), для предварительной приемки (на этапе «3» подготовка к опытной эксплуатации - члены комиссии предварительных испытаний), для проведения комплексного тестирования в условиях, близких к рабочим условиям (в ходе опытной эксплуатации на этапе 4), для приемки результатов проекта (на этапе 5 «Перевод в промышленную эксплуатацию»);
- во-вторых, привлечение сотрудников заказчиков в качестве членов команды внедрения.
Следует понимать, что участие сотрудников как по первой группе, так и второй, предполагает частичное отвлечение их от основных обязанностей в рамках их компании. Поэтому привлечение каждого их них должно согласовываться с уполномоченным представителем заказчика.
Крайне желательно до беседы сделать предварительный набросок плана коммуникации по ролям и предварительно получить одобрение кто, когда и на какой срок может быть отвлечен.
По результатам данной активности необходимо составить перечень:
- роль (например, интервьюируемый по прикладной области «такой-то»);
- ФИО и должность;
- период привлечения (здесь очень ориентировочно);
- объем привлечения.
Нам данная информация понадобится не только для плана проекта, но еще и для устава и плана коммуникаций. Ну а ответственному за проекта со стороны заказчика подготовка данной информации также будет не лишним - ведь ему также придется согласовывать привлечение данных сотрудников с их руководителями.
Итоги
Собственно это далеко не полный перечень информации, который нужно получить в ходе предпроектной подготовки, но для подготовки общего плана проекта ее будет вполне достаточно.
Далее на основании вот этой информации подготавливается план проекта, аналогичный тому, который я расписывал в публикациях, ссылки на которые указаны в начале статьи. Далее план предварительно согласуется и уже на основании его подготавливается КП и драфт устава проекта. Также на основании него готовится бюджет проекта.