Формальное обращение, необходимое для получения официального разрешения на изменения в предметной области проекта, проектных решениях, методах, плановых сроках и затратах или других показателях проекта.
Запрос на изменение должен быть задокументирован, зарегистрирован и оценен. Выполняются только одобренные запросы на изменения.
запрос на изменение Формальное предложение на реализацию изменения. RFC включает в себя детальное описание предложенного изменения, и может быть записано в бумажном или электронном формате. [http://www.dtln.ru/slovar-terminov]
Тематики
запрос на изменение RFC (ITIL Service Transition) Формальное предложение на выполнение изменения. Запрос на изменения включает в себя детали предложенного изменения и может быть записан в бумажном или электронном виде. Термин «запрос на изменение» часто неверно употребляется в значениях «запись об изменении» или «изменение» само по себе. [Словарь терминов ITIL версия 1.0, 29 июля 2011 г.]
request for change RFC (ITIL Service Transition) A formal proposal for a change to be made. It includes details of the proposed change, and may be recorded on paper or electronically. The term is often misused to mean a change record, or the change itself. [Словарь терминов ITIL версия 1.0, 29 июля 2011 г.]
Тематики
заявка на внесение изменений (в проект) — [А.С.Гольдберг. Англо-русский энергетический словарь. 2006 г.]
Тематики
2.11 заявка на изменение (request for change): Заполненная бумажная или экранная форма, содержащая детальные сведения о существе заявки на изменение какого-либо элемента конфигурации, связанного с услугой или инфраструктурой.
Полезное
Смотреть что такое «request for change» в других словарях:
Request for Change — Eine Änderungsanforderung bezeichnet im Änderungswesen von Projekten einen formalisierten Wunsch nach Veränderung der Eigenschaften eines bestimmten Produktmerkmals. Jede Änderungsanforderung sollte in einem kontrollierten Prozess bewertet,… … Deutsch Wikipedia
Request for Information — A Request for Information (RFI) is a standard business process whose purpose is to collect written information about the capabilities of various suppliers. Normally it follows a format that can be used for comparative purposes.So an RFI is… … Wikipedia
Request for enhancement — Sommaire 1 Informatique 2 Économie 3 Notes et références 4 Liens internes Informatique Une request for enhance … Wikipédia en Français
Request for production — Civil procedure in the United States Federal Rules of Civil Procedure Doctrines of civil procedure Jurisdiction Subject matter jurisdiction Diversity jurisdiction Personal jurisdiction Removal jurisdiction Venue Change of venue … Wikipedia
Request for Comments — In computer network engineering, a Request for Comments (RFC) is a memorandum published by the Internet Engineering Task Force (IETF) describing methods, behaviors, research, or innovations applicable to the working of the Internet and Internet… … Wikipedia
Request for permission to withdraw or modify a motion — infobox motion name = Request for permission to withdraw or modify a motion inorder = If not granted by unanimous consent, can be moved by person requesting permission, or by another while the former has the floor seconded = Yes, if… … Wikipedia
Change Management (ITIL) — Change Management ist ein Themengebiet aus der IT Infrastructure Library (ITIL) und wird dort im Buch Service Transition als Prozess definiert, der das Ziel hat, dass alle Anpassungen an der IT Infrastruktur kontrolliert, effizient und unter… … Deutsch Wikipedia
Change request — A change request is a document containing a call for an adjustment of a system; it is of great importance in the change management process. A change request is not raised for a wording change in a letter. A change request is declarative, i.e. it… … Wikipedia
Change management analyst — A change management analyst is responsible for auditing and evaluating the change management process of a business.[citation needed] Change management is aimed at helping system users to adopt the new system and use it productively. The role of… … Wikipedia
Change Request — Eine Änderungsanforderung bezeichnet im Änderungswesen von Projekten einen formalisierten Wunsch nach Veränderung der Eigenschaften eines bestimmten Produktmerkmals. Jede Änderungsanforderung sollte in einem kontrollierten Prozess bewertet,… … Deutsch Wikipedia
Change control — within Quality management systems (QMS) and Information Technology (IT) systems is a formal process used to ensure that changes to a product or system are introduced in a controlled and coordinated manner. It reduces the possibility that… … Wikipedia
Software Configuration Management // отслеживание запросов на изменение
Вместо предисловия
И снова доброго времени суток!
Отслеживание запросов на изменение
Изменяться может любой рабочий продукт – это могут быть как исходные коды, так и требования, тесты – в общем, всё то, что перечислялось в предыдущих материалах. Важно, что это всё изменяется и надо производимые изменения контролировать.
В зависимости от вида и продукта изменения различается и источник его запроса. В случае новой функциональности это будет, скорее всего, один из менеджеров или конечный пользователь. При рефакторинге – технический руководитель или разработчик проекта. При исправлении ошибки – любой пользователь системы, но, как правило, это тестер.
Итак, есть потребность в изменениях, и есть тот, кто эту потребность озвучит. Остается начать движение. Началом движения является подача запроса на изменение. Запрос на изменение – это предложение об усовершенствовании продукта, выраженное в виде записи в системе отслеживания запросов на изменения. В англоязычных источниках такие запросы называются change request (CR). Встречается также термин problem or change request (PCR). В дальнейшем будем использовать аббревиатуру CR (читается «сиар»).
В свою очередь, система отслеживания запросов на изменения – это программная среда, позволяющая производить учет предложений на изменения продукта и управление ответственностью за них. Ключевые слова во всей цепочке терминов – запрос, изменение, и отслеживание ответственности. В русскоязычных источниках часто используется термин «система отслеживания ошибок». В англоязычной литературе встречаются change request management system, bugtracking system, issue tracking system.
Посмотрим на типовой сценарий. Запись заведена, нужно начинать работать. Однако никакие изменения не должны вноситься бесконтрольно. Поэтому перед началом работы нужно получить одобрение менеджмента, который отвечает за функциональность, затронутую запросом на изменение. Роль менеджмента выполняет Configuration Control Board (группа контроля конфигурации) – группа, обладающая в рамках проекта правами на управление изменениями в рамках проекта. Также иногда используется термин Change Control Board и сокращение CCB.
Простой сценарий
Для дальнейшей работы возьмем систему отслеживания в виде машины состояний – так будет более наглядно. Набор состояний на схеме 1 – минимально необходимый, он может быть расширен до большего размера и разбит на нескольких шаблонов жизненных циклов. Этот набор возьмем для дальнейшего описания.
Схема 1. Жизненный цикл запроса на изменение
Первое состояние, в которое попадает любая запись, начальное. На приложенной схеме это New. На этом этапе создатель записи вносит все начальные данные, требуемые проектным процессом разработки. Далее CR попадает в поле зрения CCB. Оно принимает решение, кому из разработчиков отдать проблему для решения.
Для того, что отдать CR в работу, запись переводится в следующее состояние – Assigned («приписано к ответственному»). Одновременно запись «назначается» на разработчика – т.е. он становится за неё ответственным.
Однако приписать задачу кому-то – ещё не означает, что задача сразу же начнет решаться. На одного разработчика ведь может быть назначено несколько задач – одна важней другой и все надо сделать ещё вчера. Поэтому когда разработчик на самом деле начинает заниматься задачей – он переводит запись в состояние Opened («работа начата»). CCB, отслеживающее работу, видит, что задача взята в оборот. Сама задача при этом, как правило, остается «приписанной» к разработчику.
По ходу работы ответственные могут меняться, в зависимости от того, кто владеет кодом, который влияет на описанное в CR поведение. Переназначения делает CCB. Кроме того, может выясниться, что проблема уже кем-то найдена и на неё был заведен свой CR. В этом случае проблема дуплицируется, т.е. закрывается и в соответствующем поле добавляется номере записи, которая была заведена ранее. С этого момента запись считается закрытой. Может также выясниться, что описанная проблема не является ошибкой в работе (т.е. это WAD, works as designed) или же запрошенная функциональность не может быть реализована в силу разных причин. В этом случае запись терминируется, т.е. закрывается с комментариями о том, почему работа над проблемой продолжена не будет.
Об реализации и тонкой настройке
Кстати, стоит добавить, что системы отслеживания запросов на изменения также используются как системы назначения и отслеживания задач на проекте. Ведь любая задача, возникающая на проекте, требует отслеживания со стороны руководства. Да и результат большинства задач – это, опять же, какие-то изменения. Поэтому логично для всех целей использовать одну систему. Иногда системы отслеживания задач ещё называют общим термином help desk. Однако, смысл от этого неменяется — я их также причисляю к системам отслеживания запросов на изменение.
Если предложенный жизненный цикл не подходит по каким-то причинам, большинство систем отслеживания позволяют этот цикл модифицировать и создавать несколько его видов – столько, сколько нужно для решения повседневных задач. Кстати, именно поэтому часто создают отдельные шаблоны для отслеживания разработки новой функциональности и для отслеживания процесса исправления ошибок. Просто потому, что при разработке новых возможностей требуется ещё и разработка требований, дизайна, тестов – и для этого вводятся промежуточные состояния или поля для перечисленных целей.
Моё мнение — надо выбирать системы, позволяющие гибко задавать цикл работ. Хотя бы для того, чтобы заложенная когда-то кем-то неведомым схема работы не стала для вашего проекта догмой. Со временем за её рамки трудно выйти из-за ограничений инструментария и проекту начинает становиться «тесно». Так что гибкая настройка — наш выбор!
Реализация систем отслеживание запросов на изменения – едва ли не любимейшее занятие программистов всего мира. Кто-то считает, что его система-то уж точно затмит все имеющиеся. Кто-то уверен, что в остальных чего-то не хватает из того, что надо ему. А кто-то просто делает это ради собственного удовольствия. Каждому – своё. Если кто не захочет изобретать своё двухколесное средство передвижения, может ознакомиться с существующим велопарком. Ну и подобрать бицикл, что лучше всего подходит для его задачи. К слову, автору довелось принять некоторое участие в разработке упомянутого в приведенном списке eTraxis. Его и порекомендую, пользуясь случаем.
А как же CM-инженеры?
Ссылки для расширения кругозора
В следующей части будет расказано о, пожалуй, самом важном проявлении практик SCM — контроле версий. Кстати, там снова будет затронуто отслеживание запросов на изменения — без него никуда.
Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров
участников являются сотрудниками ИТ-компаний
20% из них — совладельцы бизнеса
работают в ИТ-службах других компаний
Авторизация
Новым пользователям
Зачем?
«Запросы на обслуживание» или «Изменения»?
Чуть больше недели назад на страницах сообщества был поднят вопрос о формулировании сложных запросов на обслуживание в рамках ITIL. Обсуждение первоначальной проблематики в комментариях к вопросу быстро свелось к спору о том, какой в данном случае лучше применять тип процесса – управление изменениями или запрос на обслуживание. Для разъяснения ситуации приведу вольный перевод статьи на эту тему специалиста по ITSM из Индии, Винода Кумара Аграсала (Vinod Kumar Agrasala).
Что характерно, статья в блоге специалиста появилась именно потому, что он регулярно сталкивается с дискуссиями на эту тему в социальных сетях и профессиональных сообществах. Свои разъяснения он построил на разборе четырех наиболее часто встречающихся вопросов. В некоторых позициях ответы, конечно, касаются совсем «базовых» вещей, однако его подход хорошо «раскладывает по полочкам» всю тематику:
Вопрос 1. Как отличить запрос на обслуживание от запроса на изменение?
Запросы на обслуживание (service request) – это запросы, поступающие от пользователя к технической поддержке. Они исполняется через Обработку запросов на обслуживание (request fulfillment). А запросы на изменения (change request) появляются в том случае, если необходима модификация сервиса, системы управления услугами или других основных систем и компонент.
Запрос на обслуживание (service request) может включать в себя некоторые изменения (change request), но если пользователь имеет право их запросить (перечень таких прав часто определяется «Стандартными запросами пользователей»).
Для выполнения запросов, связанных с изменениями, применяется процесс управления изменениями (change management). На практике при выполнении таких запросов два и более процессов могут выполняться параллельно (что вполне допустимо в рамках управления изменениями), а одновременно с обработкой запроса на обслуживание (request fulfillment) не может осуществляться ни управления изменениями, ни управления релизами, ни управления доступом. Ситуация очень напоминает решение проблемы (или инцидента): требуется некоторое изменение, соответственно, последует процесс управления изменениями.
Важно отметить, что изменения, которые запрашивают пользователи, часто бывают незначительными, т.е. оперативными (установка настольного ПО, изменение пароля и т.п.). Как правило, они попадают под модель стандартных (предварительно согласованных) изменений. Для их реализации не требуется проходить через процедуру согласования изменения, поэтому нет необходимости следовать процессу управления изменениями во всех деталях.
Вопрос 2. Все ли стандартные изменения выполняются посредством обработки запросов на обслуживание?
Нет, такой путь возможен только для стандартных изменений, запрошенных пользователем (т.е. поступивших в виде запроса на обслуживание). Другие стандартные изменение, инициированные ИТ-службой (к примеру, обновление антивируса, рутинные эксплуатационные изменения и т.п.) должны исполняться через стандартный процесс управления изменениями.
Вопрос 3. Все ли запросы на обслуживание, таким образом, связаны с процессом управления изменениями?
Нет. Такая связь подразумевается только для тех запросов, которые требуют изменений для удовлетворения. Запросы на обслуживание также могут быть: запросами информациями, стандартными задачами и т.п., т.е. не подразумевать никаких изменений.
Вопрос 4. Все ли изменения по просьбе бизнеса / клиентов / пользователей стоит рассматривать, как запросы на обслуживание?
Нет. С этой позиции стоит смотреть только на стандартные изменения, запрошенные пользователями. Любые существенные изменения, инициированные бизнесом (новые услуги, изменения в уровне предоставления этих услуг, новый функционал и т.п.), будут формальным запросом на изменения, причем, управляться исполнение таких изменений будет, согласно уровню взаимодействия службы и бизнеса. Обычно только клиенты (clients) имеют право генерировать такие запросы, но никак не рядовые пользователи (users).
Change request best practices to help your business win
Summary
Change requests are a fundamental tool within change management, which itself is one of the most important processes in IT service management (ITSM). This is because everyone makes changes regularly. Change requests provide a standardized approach when asking for change to be made, supporting effective and consistent review and approval, and assisting with the management of risk. Therefore, it is vital that every organization gives detailed consideration to how they intend to use change requests.
What is a change?
In ITSM a change is defined as the addition, modification, or removal of anything that could have an effect on IT services. Change management is the process responsible for managing and controlling the lifecycle of all changes. This includes requesting changes.
The scope of change requests includes changes to IT applications, networks, servers, desktops, laptops, tools, architectures, processes, organizational structures, and operating instructions. The change management process includes requesting a change, and the recording, reviewing and approving of the change request.
What is a change request?
A change request is a formal request for a change to be made. The change request includes details of the proposed change. A change request is also known as a request for change or an RFC. Any request for change can be recorded on paper or digitally.
It is important to understand the difference between a change request and the subsequent change record. A change record is created using information from the change request but is then updated as the change progresses through its lifecycle with additional information.
This is in contrast with the change request, which should not be updated once it has been accepted and a corresponding change record has been created. It is also important to differentiate between the change request and the change itself. It is the change that gets implemented, not the change request or RFC.
What are the different types of change request?
There is only one type of change request, however, some organizations use different templates depending on the type of change, and the type of asset affected by the change:
Types of changes
Changes can be emergency, standard, or normal. Each is likely to require a different change request template.
Type of asset
Different types of asset are very likely to require different information in the change request to support its review and assessment. For example, a request to change the configuration of networking equipment assets will probably require the IP and MAC address of the equipment, as these uniquely identify it in the network.
In order to ensure standardization of requests to change networking equipment, they can have their own change request template with these addresses as mandatory entries. In the same way, requests to change process assets could have their own change request template that includes the process name as a mandatory entry.
Why are change requests important?
Change requests provide a formal mechanism to ask for a change to be made and evaluated, and assist with the necessary control over this process. Change requests assist in standardizing the information presented when making the request, which assists in the review and evaluation of the requests. Change requests also help to manage the risks inherent in making changes, by forcing the change requestor to consider the detail of the intended change.
Using change requests ensures that the details of what the requestor wants are recorded in a consistent way. If instead of using change requests, requestors ask individuals in IT to do something there is a high risk that the request is forgotten about, or the necessary information required to evaluate the change isn’t available, or is incomplete. This presents a risk to the organization of changes that disrupt the business activities.
Where do change requests fit into the ITIL methodology?
Change requests are an important element of the ITIL change management process. ITIL uses the term ‘request for change’ which is usually abbreviated to RFC. RFCs are used in the first stage of the ITIL change management process as a proposal where the requestor provides details of their proposed change.
Once the change request has been created, it is logged by the team in ITSM responsible for change management. The request for change is then reviewed to check that it is complete, and prioritized for business practicality. If incomplete, the change request can be rejected and returned to the requestor, or they can be asked to provide more detail. Once the change request has been accepted, the information in it is used to create a change record, which documents the lifecycle of a single change.
This change record should reference all configuration items that are affected by the change, even if these are not listed in the change request. The change request is then circulated to key stakeholders for evaluation, including an impact assessment. The outcome from the evaluation of the change request is used to determine if the change request is approved. Once approved, the change detailed in the change request can be implemented.
