중요한 고려 사항은 서비스의 수와 형태이다. 서비스의 수는 서로 다른 "팀" 이 부서, 그룹 또는 다른 직책인지 결정합니다. 운영 차원의 조직 구조를 설계하는 것은 사실상 서비스를 제공하는 방식을 설계하는 것이다. 우리는 세 단계로 생각할 수 있습니다: 1) 고려해야 할 서비스 2) 서비스를 제공하는 방법 3) 서비스가 얼마나 복잡한지, 다른 팀이 완성해야 합니까? 즉: 1) 첫째, 서비스가 얼마나 복잡합니까? 서비스 카탈로그입니다. 사용자 사용을 지도합니까? 시스템 구성 도움말? 시스템 결함 수정? 시스템 업그레이드가 필요하십니까? 2) 둘째, 서비스 카탈로그에 따라 서비스 제공 방법을 설계할 수 있습니다. 예를 들면 뭐죠? 원격 해결, 현장 서비스, 현장 수정? 리모델링? 3) 마지막으로, 서비스는 얼마나 복잡합니까? 어떤 팀 구조가 필요합니까? 만약 네가 대답만 한다면, 그것은 단지 헬프데스크일 뿐이다. 시스템에 더 심도 있는 질문이 있다면, 2 선 기술팀이 필요하다. 현장 서비스가 필요한 경우 현장 서비스 팀을 구성해야 합니다. 시스템이 너무 복잡해서 개인이 전체 시스템을 파악할 수 없다면 서로 다른 하위 시스템에 대해 서로 다른 기술 서비스 팀을 구성할 필요가 없습니다. 시스템을 수정해야 하는 경우 개발 팀을 늘려야 합니다. 또한 유지 관리, 개발 및 구현 간의 인터페이스도 고려해야 합니다.