Служба заказчика

при заключении договора на оказание услуг обычно составляется регламент оказания этих услуг, в котором указано каким образома по какому графику исполнитель эти услуги оказывает и каким образом Заказчик эти услуги контролирует и принимает

В русском языке в конце вопросительных предложений принято ставить вопросительный знак.

На самом деле ваш вопрос касается нескольких сфер. Первое. что вам следует изучить - стандарт ITIL, см. ссылки.
Ну и еще - попробуйте немного ознакомится с идеологией MRP II и ERP, что позволит понять зачем нужно ITIL.
И весьма рекомендую изучить опыт Intel в этом вопросе - они в этом многого достигли и готовы делиться информацией.

Zhumak  
я знаю что такое ITIL спасибо, знаю что такое Cobit и ISO 20000. но в этих документах нигде (по крайне мере я не нашел) явного указания на целесообразность разделения службы заказчика и исполнителя, что они не должны быть частью одно подразделения. единственное место в ITIL где об этом идет речь это SLM. и там это выглядит так:
- Заказчик — это представитель организации, у которого есть полномочия на заключение соглашений от лица организации на получение ИТ-услуг. Поэтому заказчик и конечный пользователь услуг — не одно и то же.
- Поставщик — это представитель организации, у которого есть полномочия на заключение соглашений о предоставлении ИТ-услуг.
в данном случае непонятно почему Заказчик и Поставищик не могут быть одним лицом, или двумя людьми в рамках одного отдела например.
Можно какие нибудь ссылки на опыт INTEL по данному вопросу?
или вы имеете ввиду Intel-ОВСКУЮ интерпретацию ITIL, аналогичную Microsoft-вскому MOFу, или ITIL от HP?

Представим себе, что Вы работаете в IT-отделе некой организации (холдинга), и в обязанности вашего отдела входит поддержка некой ERP-системы.  
Допустим, у вас есть главный бухгалтер вашего холдингу, который постоянно что-то хочет – то ему здесь кнопочку прилепить, то такой вот отчетик прилепить, то добавить вот такую автоматизированную последовательность операций, то еще что-то. И пусть такой бухгалтер создает Вам загрузку на уровне 120 рабочих часов в месяц. Если пересчитать в затраты, то фактически это будет 1 сотрудник IT-отдела, который большую часть времени занят удовлетворением одного пользователя.
А теперь «ужесточим» ситуацию – это бухгалтер заказывает доработки, не используемые остальными 20 бухгалтерами, и их польза – только для одного человека. При это м на выполнение тех задач, на которые этот бухгалтер тратит 1 час в одни раз в месяц, вам приходится выделять по 20-30 часов рабочего времени специалистов вашего IT-отдела.
Сточки зрения хозяев вашей организации – это плохая ситуация, т.к. они платят беспрерывно за работу, реально не улучшающую характеристики их ERP-системы. Но с точки зрения начальника IT-отдела – это хорошая ситуация, потому как получается больше сотрудников у него в подчинении, больший объем работ, а значит, он может претендовать на большую з/п.
Довольно часто, даже если начальник IT-отдела является противником такого рода доработок, он не может их прекратить, т.к. является в немалой степени человеком зависимым, в т.ч. от этого главного бухгалтера.
Именно для исключения таких «закольцовываний» водится, кроме «Конечного пользователя» понятие «Заказчик», который представляет интересы организации (допустим,  это финансовый директор), и могущий выступить в роли «Третейского судьи» при определении необходимости и целесообразности таких доработок.
У «Заказчика» нет ни малейшей заинтересованности раздувать штат IT-отдела, скорее даже наоборот, он будет стремится сократить затраты на IT-отдел, а для этого надо уменьшать к-во сотрудников, а значит стимулировать максимальную эффективное использование имеющихся.
В общем, не совсем научно, но вроде – по сути.

Предыдущее - это объяснение, почему не может быть одним лицом (или в одном подразделении) Заказчик и Поставщик. Забыл указать, извините.

Zhumak
Спасибо за вашу точку зрения, она безспорно логична и верна.
Я могу придумать еще тысячу доводов:
2. Служба заказчика ориентирована на бизнес-потребности, а исполнители ориентированы на выполнение работ.
3. У Службы Заказчика есть возможность и полномочия влиять на ИТ бюджет – оптимизировать его, у исполнителя нет ни потребностей ни возможностей, он заинтересован в освоении бюджета.
4. Контролирующие и исполнительские функции не должны управлять одним лицом (за исключением генерального директора). Иначе теряется смысл контроля.
5. Служба заказчика разговаривает на «языке» бизнеса.
6. Служба заказчика по одинаковым объективным требованиям оценивает работу внешних и внутренних подрядчиков
7. Формирование ИТ – сервисов происходит в соответствии с требованиями заказчика – бизнеса, а не с точки зрения техн. специалистов.
8. Параметры качества сервисов согласованы с бизнесом и выбран поставщик удовлетворяющий этим требованиям (совмещенная служба заказчика и исполнителя не могут обеспечить данного условия, т.к. не может быть осуществлен адекватный выбор поставщиков)
9. Усилия ИТ сфокусированы на КЛЮЧЕВЫХ направлениях, а не на том что может и умеет внутреннее ИТ.
10. Планируется и осуществляется работа по улучшению качества и мониторингу качества (исполнитель в этом не заинтересован)
11. Стоимость услуг внутреннего подразделения формируется на конкурентной основе.
12. Служба заказчика «учит» производство считать деньги.
13. Топ менеджмент не общается напрямую с тех. специалистами, не вникает в тех. вопросы, он общается со СЗ на уровне качественных и количественных параметров услуг
да все верно и логично.
НО вопрос стоял немного по другому. Где есть требования по реализации "службы заказчика" и где впервые описана данная концепция