В чем разница между ITIL и SDLC с точки зрения обслуживания?
Мое понимание SDLC означает, что он состоит из этапов планирования, проектирования, кодирования, сборки, развертывания и поддержки приложения. В свою очередь, каждый состоит из подэтапов, таких как управление кодом или управление конфигурацией, управление выпусками и т. Д., Особенно в гибких методологиях. Таким образом, все эти этапы и подфазы представляют собой практическую книгу для разработки приложений.
В последнее время (новичок и новичок в ITIL), читая практики ITIL, особенно его жизненный цикл, я не смог получить никакого преимущества от ITIL перед SDLC, за исключением многократного повторения слова "обслуживание" в ITIL.
Что означает ITService, потому что это сильно подчеркивается в ITIL? И как это определяющее слово "сервис" делает ITIL выгоднее SDLC? В поиске с помощью Google я нашел это определение: "Средство доставки ценности для клиента путем облегчения результатов, которые клиент хочет достичь, без учета конкретных затрат и рисков". Но все же я не могу понять его преимущество. Если нет различий между их фазами, то какой смысл в существовании двух моделей.
Конечно, вышеизложенное объяснение - мой способ понимания из-за неспособности понять различия и слово "обслуживание". Я прошу любого пролить свет на вышеуказанную тему.
4 ответа
В моей организации мы не используем стандарты ITIL для руководства проектом или задачей по разработке программного обеспечения. Вместо этого мы используем ITIL для управления нашими сервисными моделями обслуживания клиентов.
Например, наша система регистрации неисправностей использует номенклатуру и принципы ITIL для сортировки, классификации и отслеживания проблем с программным обеспечением. Когда пользователь сообщает о проблеме, отправляя заявку, мы следуем стандартам обслуживания ITIL, которые рекомендуют, чтобы для обеспечения наилучшего обслуживания мы делали все, что нам нужно, для разрешения инцидента, даже если это означает введение обходного пути., Это обеспечивает хороший сервис для клиентов, так как минимизирует время простоя клиента.
После восстановления операции (с помощью обходного пути или быстрого исправления ошибки) для последующей работы по программированию создается долгосрочная проблема, дефект или элемент расширения. Именно на этом этапе мы внедряем наш процесс SDLC, чтобы расставить приоритеты при разработке и выпуске (бизнес-обоснование, одобрение совета директоров, сбор требований, программирование, QAT, UAT, выпуск и т. Д.).
Таким образом, в итоге мы используем ITIL в первую очередь для наших процессов обслуживания клиентов. SDLC используется внутри компании для фактического отслеживания и управления логистикой разработки программного обеспечения до ее завершения.
До сих пор я видел два таких подхода: когда у меня есть Система, которая обеспечивает ценность для моих клиентов, я использую методологии ITSM, чтобы гарантировать, что этот сервис соответствует максимальному потенциалу, постоянно удовлетворяя ожидания моих клиентов. Управляя своими ИТ-услугами, мы находим возможность для изменений, я использую SDLC для создания и предоставления изменений, которые были выявлены с помощью моей практики ITSM. Между этими двумя линиями есть определенно совпадающие действия, но они, по сути, служат друг другу. SDLC ориентирован на продукты, ITSM ориентирован на обслуживание клиентов.
Будучи самым неосведомленным в этом вопросе, ниже приведены мои 2 цента по этому вопросу (на которые я также пытаюсь найти ответ): Насколько я понимаю, было бы легко расшифровать эту проблему, если бы мы поняли, как после внедрения поддержка обычно запланирована. В идеальном сценарии планирование службы после развертывания должно начинаться прямо на этапе разработки приложения, когда анализируются функциональные и нефункциональные требования. Это связано с тем, что в настоящее время мы должны начать привлекать оперативных сотрудников, которые будут поддерживать приложение в PRODUCTION и поэтому несут ответственность за подготовку службы поддержки, разработку обходных путей для известных недостатков проекта, внесение изменений в базу данных об известных ошибках, обновление конфигурации база данных управления, настройка рабочих процессов управления доступом и т. д. (все, о чем говорит ITIL)
Таким образом, ITIL перекрывается с SDLC, но предоставляет более подробные рекомендации по управлению сервисами после развертывания приложения (фаза обслуживания SDLC). Из того, что я видел, почти все платформы SDLC дают очень ограниченное руководство по этому этапу SDLC, и именно поэтому ITIL восполняет этот пробел. По сути, организации необходимо объединить два процесса, чтобы получить максимальную выгоду (фактически, картина не будет полной, если не будут интегрированы другие структуры для управления ИТ + управление качеством + управление безопасностью). Суть заключается в следующем: ни одна интегрированная среда не способна управлять всем жизненным циклом ИТ, вам нужно много смешивать и сопоставлять, чтобы достичь нужного уровня глубины и широты процессов для вашей организации.
Наконец, что касается путаницы между приложениями и услугами, то, как говорят в маркетинге, у вас редко бывает чистый продукт или услуга. Обычно это интегрированное предложение, в котором оба дополняют друг друга, образуя весь опыт клиента. Тем не менее, я думаю, что разграничение между продуктом и обслуживанием имеет большее значение для поставщика услуг, чем для потребителя услуг. Сказав это, ITIL, кажется, больше сосредоточен на предоставлении высококачественного обслуживания для продукта / приложения (независимо от того, насколько хорош или дрянен продукт).
На простые вопросы сложно ответить:) При использовании Википедии можно встретить такое определение "Сервис":
Служебный (от самца животного) мат с (самкой животного). "одна собака может обслуживать несколько сук за день"
поэтому я предпочитаю смотреть, что говорят лидеры мнений...
IT Skeptic (Роб Инглэнд) хорошо известен профессионалом в "области фреймворков" и здесь его 2 версии и мысли:
- ИТ-услуги - это транзакции по технологии.
- ИТ-услуга - это предложение и / или потребление типа транзакции, выполняемой по технологии.
Когда вы проверите обсуждение в этой статье, вы легко найдете другие альтернативы и ссылки на:
- USMBOK Ян Клейтон
- CMMI-SVC определение "продукт, который нематериален и не подлежит хранению" и т. Д.