Форум Сообщества Аналитиков

×


Требования к Заказчику и Исполнителю(Прочитано 13146 раз)
Всем привет! :)
Друзья!
Предлагаю обсудить ряд вопросов:
- Каким должен быть Заказчик и Исполнитель?
- Какие требования к Заказчику?
- Какие требования к Исполнителю?
- Согласны ли вы, что каждый договор подобен брачному контракту, в котором главное, что будет иметь каждая из сторон, когда отношения прекратятся?
Знания могут придать человеку вес, но только воспитанность может придать ему блеск.



- Какие требования к Заказчику?

Я бы конкретизировал этот вопрос. Он распадается на два:
1) Требования к Заказчику в проектных процедурах
2) Квалификационные требования к представителю заказчика

Рассуждать о Заказчике вообще, и об Исполнителе вообще бессмысленно. Любая организация, которой надо решить какую-то проблему и у нее есть на это деньги потенциально удовлетворяет требованиям заказчика.

А вот, чтобы проблема решилась, то необходимо грамотно организовать проект. На вопрос как это сделать отвечает специальная наука - управление проектами (она конечно связана с анализом, но прямого отношения к нему не имеет). Опыт успешного управления зафиксирован в специальном своде -   https://ru.wikipedia.org/wiki/%D0%A1%D0%B2%D0%BE%D0%B4_%D0%B7%D0%BD%D0%B0%D0%BD%D0%B8%D0%B9_%D0%BF%D0%BE_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8E_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%D0%BC%D0%B8

В этом своде достаточно подробно описаны различные варианты проектных процедур, и роли каждого участника процесса.

Из этого следует другой вопрос - персональный. А именно, какие требования есть к должностному лицу, который от заказчика участвует в проектных процедурах.

Для начала надо понять, как вообще называется эта должность, прежде чем начинать предьявлять к ней требования.

В коммерческих структурах она зачастую так и называется - руководитель проекта внедрения. Если таких РП в организации много, обычно их распределяют по подразделениям. Довольно удачное название для этой должности в X5:

IT бизнес-партнер

Цитировать
Обязанности:

    действие в качестве представителя всей дирекции ИТ по существующим проектам, обеспечение интерфейса между подразделениями  ИТ и бизнесом;
    обеспечение соответствия ИТ-разработок по проектам и операционной деятельности  бизнес-интересам;
    аккумулирование бизнес-запросов и требований структурных подразделений компании, определение бизнес потребностей и ИТ возможностей;
    управление проработкой проектной деятельности по ИТ системам и приложениям (затраты/выгоды, риски, сферы применения, планирование);
    курирование портфеля ИТ проектов в рамках бюджета;
    отслеживание использования ИТ-систем и инструментов;
    взаимодействие с внешними подрядчиками при проработке проекта;
    консультирование бизнеса на предмет имеющихся ИТ-услуг и решений.

 

Требования:

    высшее техническое образование;
    руководящий опыт работы;
    опыт внедрения и доработки ИТ систем для крупных торговых или логистических компаний (WMS, TMS, SAP);
    высокие коммуникативные и аналитические навыки, опыт проведения коммуникаций с бизнесом на высоком уровне;
    English - Intermediate.




Как видно, требований к квалификации ни системного аналитика, ни бизнес аналитика не предьявляется вообще. Тем не менее такой специалист должет уметь как минимум пользоваться результатами анализа, а иногда первичный анализ осуществлять самостоятельно.

В описании конкретно этой вакансии очень много скрыто во фразе опыт внедрения и доработки ИТ систем

Там собственно и живут требования к РП, и к аналитику.

Но могут выделить их и отдельно.

В государственных структурах и госкомпаниях  все сложнее. Штатные расписания жесткие, поэтому вменить обязанности представителя заказчика могут кому угодно. Проще всего, если в государственной структуре есть Единая дирекция заказчика. Зачастую она занимается всем - и IT, и строительством , то есть практически любые инвестиции.

Но если проект организован грамотно, то функции и квалификационные требования примерно те же.



Можно заглянуть сюда:
http://www.uml2.ru/forum/index.php?topic=202.0
http://processimpact.com/articles/customer.html
http://processimpact.com/articles/be_analyst.pdf

А вообще у Вигерса все это есть и подробно...
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



- Согласны ли вы, что каждый договор подобен брачному контракту, в котором главное, что будет иметь каждая из сторон, когда отношения прекратятся?

Стеб и ирония детектед. А между прочим совершенно зря - IT проекты были и остаются одними из самых высокорисковых классов проектов. Не даром, когда говорят про стартап или венчур в 99 % случаях имеют в виду именно IT венчур или стартап.

Цитировать
В России ежегодно вступают в брак чуть более 1 миллиона пар, при этом около 700 тысяч семей подают на развод.

Не в курсе статистики относительно того, как влияет грамотный брачный контракт на сокращение числа разводов, но совершенно точно грамотный контракт на IT проект резко повышает вероятность его успеха.

Происходит это по одной причине - основные причины неуспеха именно в неправильном распределении ответственности участников проекта.

В этом плане показателен пример Ciber Novasoft - это американская компания, которая осуществила прорыв SAP на российский розничный рынок. В начале 2000 годов менеджментом российских компаний был накоплен богатый опыт похеривания проектов внедрения как SAP, так и других систем. А Ciber в течении 2-3 лет половину российского ритейла умудрился перевести на SAP , но при этом маленький нюанс - половина проектов внедрения (если не больше) завершалась через суд.

Как ни странно, ведя пару-тройку судебных процессов одновременно, Ciber без труда находила себе новых клиентов.

Ларчик открывался просто - при жестких контрактных обязательствах Заказчика и Исполнителя друг перед другом проектные процедуры работали как часы - крайним оставаться никто не хотел...



Проще всего, если в государственной структуре есть Единая дирекция заказчика. Зачастую она занимается всем - и IT, и строительством , то есть практически любые инвестиции.

В этом случае просто получается два заказчика: формально-административный в лице единой дирекции, и функциональный в лице тех, кому с результатами проекта жить. Ой не сказал бы, что так "проще всего". По моему опыту - ровно наоборот.



В этом случае просто получается два заказчика: формально-административный в лице единой дирекции, и функциональный в лице тех, кому с результатами проекта жить. Ой не сказал бы, что так "проще всего". По моему опыту - ровно наоборот.

Формально-административный как правило не зря хлеб свой ест. В функциональные требования он не лезет, зато за качеством проектных процессов следит очень хорошо. Но это опять же по моему опыту. Понятно, что придурок на этом месте способен очень сильно осложнить жизнь как функциональному заказчику, так и исполнителю.




Ларчик открывался просто - при жестких контрактных обязательствах Заказчика и Исполнителя друг перед другом проектные процедуры работали как часы - крайним оставаться никто не хотел...

Настолько "не хотел", что компании приходилось вести по 2-3 судебных процесса одновременно. Вот уж наладили процессы, так наладили. :)



Формально-административный как правило не зря хлеб свой ест.

Ох, не зря. Объемы работы создает заметные.

В функциональные требования он не лезет, зато за качеством проектных процессов следит очень хорошо. Но это опять же по моему опыту.

Нередко такое очень хорошее слежение имеет много общего с итальянской забастовкой.



Настолько "не хотел", что компании приходилось вести по 2-3 судебных процесса одновременно. Вот уж наладили процессы, так наладили. :)

А почему ПРИХОДИЛОСЬ? Это у нас отношение к суду такое, что лучше друг друга в бетон закатают или в интернетах помоями обольют, чем в суд обратятся. У американских компаний совершенно в порядке вещей совершенно замечательно продолжать работать по проектам, оспаривая друг у друга в суде какую-нибудь фигню.

Суды образовывались потому, что когда наступало какое-нибудь событие, предусмотренное контрактом, никто ничего под ковер не заметал, все актировалось и предъявлялось. Ну и попытки поспорить быстро оканчивались в суде.

Менеджмент Ciber кстати организовал свою фирму - Novardis, которая продолжает успешно окучивать российский ритейл теми же методами. Крайний раз утечка была
http://www.comnews.ru/node/75847
, что-то они с Enter и Техносервом что-то не поделили....

При этом продожают оставаться одним из основных партнеров SAP на протяжении уже десятка лет, выступают вместе со своими клиентами на сапфорумах :)






А почему ПРИХОДИЛОСЬ?

Эмм... Они что, только и ждали повода, чтобы радостно туда побежать? Если так - то да, "приходилось" будет не очень подходящим словом. Нужно что-то вроде "ждали и надеялись". :)

Это у нас отношение к суду такое, что лучше друг друга в бетон закатают или в интернетах помоями обольют, чем в суд обратятся.

Про бетон не слышал вообще, про помои - относительно редко. Куда чаще принято договариваться полюбовно в "досудебном порядке".

У американских компаний совершенно в порядке вещей совершенно замечательно продолжать работать по проектам, оспаривая друг у друга в суде какую-нибудь фигню.

Про методы наших заокеанских "партнеров" еще в прошлую олимпиаду неплохо подметили. Мол, в следующий раз Америка отправит на соревнование не спортсменов, а юристов. Они больше медалей отсудят.

Ну и попытки поспорить быстро оканчивались в суде.

Вместо поиска компромисса. Нет, бывает так, что только суд. Сталкивался. Но чтобы это было нормальной практикой? Не, я ни разу не американец.



Re: Требования к Заказчику и Исполнителю Ответ #10 : 30 Марта 2016, 09:39:52
Друзья, спасибо большое за полезные Знания!

bas, книга Вигерса и вправду отличная! Спасибо!
Знания могут придать человеку вес, но только воспитанность может придать ему блеск.



Одно требование обязательное - совесть! :)




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19