엔터프라이즈 시스템 모범 사례

이 문서는 "트렌치에서" 컬렉션의 일부입니다. 일반적으로 엔터프라이즈 시스템(Microsoft Project Server 포함)에 대한 운영 모범 사례를 설명합니다. 엔터프라이즈 시스템은 사용자 수준에서 쉽게 사용 가능한 인터페이스를 제공하기 위해 노력하지만, 이러한 인터페이스를 제공하는 데 필요한 기술과 인프라는 매우 복잡한 경우가 많습니다. 또한 이 백서에서는 이러한 복잡성으로 인해 몇 가지 기본적인 모범 사례를 사용하여 엔터프라이즈 시스템에서 높은 수준의 안정성을 유지하는 가장 효율적인 방법에 대해서도 설명합니다.

이 문서의 Word 버전을 다운로드하려면 엔터프라이즈 관리 모범 사례를 참조하세요.

더 많은 문서를 보려면 "참호에서" 백서를 참조하세요.

엔터프라이즈 관리 모범 사례

주로 엔터프라이즈 작업표 또는 엔터프라이즈 프로젝트 관리 시스템에 대해 작성하며, 이러한 시스템과 관련하여 가장 일반적인 배포 단계는 선택 또는 구성 단계인 전략적 관점에 대해 이야기하는 것입니다. 이 문서는 운영 사례에 대해 자세히 설명하며 엔터프라이즈 작업표 또는 Microsoft Project Server와 같은 프로젝트 시스템에만 국한되지 않습니다. 오히려 일반적으로 엔터프라이즈 시스템에 관한 것이지만, 주제는 거의 모든 Project Server 배포와 확실히 관련될 수 있습니다.

이미 배포된 Project Server 시스템이 발견되거나 기존 클라이언트와 통신할 때 조직에서 시스템 및 환경을 배포하고 지원한 방법에 대해 질문하는 경우가 많습니다. 업계를 시작할 때 설치할 프로젝트 소프트웨어가 항상 최종 사용자의 PC에 상주하고 시스템 관리가 항상 로컬 개념이었기 때문에 간단한 대화였습니다. 요즘은 거의 그렇지 않습니다. 엔터프라이즈 시스템은 일반적으로 최종 사용자가 다른 웹 페이지처럼 보이는 웹 브라우저를 통해 기능에 액세스할 수 있는 인터페이스 또는 표시 수준에서 간단합니다. 이러한 시스템이 앞에 있을 수 있는 것처럼 간단한 것은 뒤쪽에 있을 수 있는 만큼 복잡합니다. 인터페이스를 표시하는 데 필요한 기술에는 여러 계층이 있을 수 있으며, 기술 및 인프라에 대한 여러 원본에 따라 달라지며(충분하지 않은 경우) 항상 업데이트될 수 있습니다.

하지만 엔터프라이즈 시스템에서 높은 수준의 안정성을 유지할 수 있는 최상의 기회를 제공하는 몇 가지 기본 모범 사례가 있습니다.

소유자 찾기

실제로 성공적인 엔터프라이즈 시스템에는 비즈니스 소유자와 기술 소유자가 모두 있기 때문에 이를 두 명의 소유자로 나누어야 합니다. 비즈니스 소유자가 IT 부서의 임원이고 엔터프라이즈 시스템이 주로 해당 부서에 대한 경우에만 소유자는 동일할 수 있습니다. 따라서 다음 두 부분으로 살펴보겠습니다.

비즈니스 소유자 찾기

이 사람은 프로젝트 관리 시스템의 결과에 대한 기득권을 가진 임원 수준 또는 고위 관리 수준 사람이어야 합니다. 시스템이 제공해야 하는 이점이나 시스템이 극복해야 하는 비즈니스 과제는 이 임원에게 직접 영향을 미치는 이점과 과제여야 합니다. 그리고, 누군가가 그것을 말하기 전에; 아니요, 일반적으로 위원회 또는 여러 사람이 될 수 없습니다.

책임은 어딘가에 놓여야하며 거의 항상 한 사람을 의미합니다. 이 사람은 시스템 구현을 위한 임원 후원자일 수도 있지만 그렇지 않을 수도 있습니다. 종종 임원 스폰서는 엔터프라이즈 시스템의 궁극적 인 비즈니스 소유자가 아닙니다.

배포 프로젝트가 끝난 후에도 비즈니스 소유자는 여전히 시스템을 소유하며, 더 이상 필요하지 않은 경우 다른 비즈니스 소유자를 식별해야 하며 시스템에 커밋해야 하거나 시스템을 사용 중지해야 합니다.

기술 소유자 찾기

엔터프라이즈 수준 시스템의 경우 기술자를 사용할 수 있는 것만으로는 충분하지 않습니다. 엔터프라이즈 시스템은 다양한 기술 계층에 의존합니다. 기술 소유자는 IT 부서의 선임 관리자 또는 임원이어야 하며, 해당 기술 계층의 소유자와 즉시 상호 작용할 수 있습니다. 여기에는 SQL Server 데이터베이스를 소유한 고위 사용자, SQL Server 설치된 데이터베이스 서버, Project Server가 설치된 애플리케이션 서버, 네트워킹, 웹 서버 또는 서버 팜, 인터넷 연결, 방화벽, Active Directory 및 Exchange 서버, 보안 서버 또는 시스템 및 클라이언트 수준 운영 체제 이미지가 포함될 수 있습니다. 선임 사용자는 환경의 다른 측면을 제어하는 관리자에게 이 엔터프라이즈 시스템을 대표할 수 있어야 합니다.

목적이 있어야 합니다.

Project Server a)에 목적이 있고 b)가 해당 목적을 충족하는지 확인합니다. 명백한 소리? 그것은 아니야. 기업 시스템이 잘못된 이유로 획득되는 경우가 너무 많으며, 시스템을 적용할 목적을 찾기 위해 IT 분야에서 다른 사람에게 넘어가는 경우가 많습니다. 엔터프라이즈 시스템의 비즈니스 목적으로 로그오프하는 사람은 비즈니스 소유자여야 하지만 다른 사람이 참여할 수도 있습니다. 나는 항상 내가 몇 년 동안 사용 한 질문을 물어, "당신은 지금 만들 수 없습니다 또는 당신은 단지 큰 어려움으로 만들 수 있습니다, 그 만들기는이 시스템의 배포에 의해 활성화됩니다?" 비즈니스 요구 사항(원하는 기능을 말하지 않음)이 해결되면 엔터프라이즈 시스템이 실제로 해당 요구 사항을 충족하는지 확인합니다. 나는 기능의 쇼핑 목록을 가지고 있지만 그들이 그들과 함께 달성하려고하는 것을 거의 이해하지 못하는 많은 사람들을 만난다.

조직이 발전함에 따라 비즈니스 소유자가 이 기본 개념으로 돌아와야 합니다. Project Server와 같은 엔터프라이즈 시스템을 배포하는 것만으로도 배포되는 비즈니스가 근본적으로 변경될 수 있으므로 시스템에 대한 조직의 요구 사항이 변경될 수 있다는 것은 놀라운 일이 아닙니다.

Project Server가 채택되고 배포된 지 몇 년 후에 조직에 들어오는 것이 일반적이므로 조직에 중요한 이유를 아는 사람을 찾는 것이 불가능합니다. 시스템이 확실히 사용 중입니다. 그것은 깎아 지른듯한 관성에서 앞으로 수행되고 있지만 목적이 손실되었으며 매일 혜택을 받는 경영진은 그 혜택이 어디에서 오는지 깨닫지 못합니다.

엔터프라이즈 아키텍처로 가져오기

몇 년 전, 저는 기술 직원 중 한 명과 함께 화가 난 고객 위치로 간 것을 기억합니다. 직접 설치한 Project Server 인스턴스로 인해 모든 종류의 문제가 발생했습니다. 직접 진행하는 동안 여러 기술 담당자를 인터뷰하고 시스템을 레이어를 통해 다시 추적해 달라고 요청했습니다. 데이터베이스 계층에 도착했을 때 깜짝 놀랐습니다. 조직의 표준 데이터베이스 서버 중 하나가 아니라 시스템을 설치한 SQL Server 버전은 최종 사용자의 PC에 있었습니다. 다시 부팅하거나 PC를 끄거나 설치할 때마다 데이터베이스를 사용할 수 없게 됩니다. 이는 말 그대로 수백 명의 최종 사용자에게 영향을 미쳤습니다.

조직은 규모가 커서 의존할 엔터프라이즈 서버나 인프라가 부족하지 않았습니다. 이 경우 문제가 쉽게 해결되었습니다. 하지만 좋은 교훈이었습니다. 배포하는 시스템이 조직이 안정적이고 안정적이며 안전한 데 엄청난 노력을 기울였을 수 있는 기존 회사 인프라에 짜여져 있습니까?

백업

알아요. 이것은 바보, 맞죠? 놀랍게도 불행히도 그렇지 않습니다. 엔터프라이즈 시스템은 동시에 백업할 시스템의 여러 측면에 따라 달라질 수 있으므로 백업하기가 매우 복잡할 수 있습니다. 물론 기본 데이터뿐만 아니라 구현의 메타데이터 및 구성 데이터도 있습니다. 또한 시스템과 일치해야 할 수 있는 보조 시스템의 모든 관련 데이터는 동일한 백업 체계의 일부여야 할 수 있습니다. Project Server를 생각할 때 프로젝트 데이터베이스뿐만 아니라 SharePoint Server 데이터베이스도 백업해야 합니다. 2010년 이전의 Project Server 버전에서는 전역 템플릿을 백업해야 할 수 있습니다. 지금도 개별 PC에 있는 템플릿의 요소가 있을 수 있습니다.

그리고 백업만으로는 충분하지 않습니다. 시스템이 변경되거나 업그레이드되면 데이터베이스 복원을 한 번 이상 수행합니다. 몇 년 전에 백업 전략을 설계하는 데 도움을 준 클라이언트와 함께 있었던 것을 기억합니다. 그는 서버를 종료하고 하드 디스크를 꺼내 다른 하드 디스크에 넣은 다음 우리를 바라보며 "거기. 하드 디스크가 방금 충돌했습니다. 이는 새로 포맷된 하드 디스크입니다. 내 Project Server를 복원하세요." 나는 뒤로 끌려 갔지만, 요청이 얼마나 좋은지 깨달았기 때문에 더 많은 것을 생각했기 때문에 아무도 이전에 (또는 그 이후로) 요청을 한 적이 없다는 것이 얼마나 충격적인지 깨달았습니다. 따라서 복원 테스트를 한 번 이상 수행합니다. 그런데 해당 시스템을 복원할 수 있었지만 의심했던 만큼 깔끔하게 다시 돌아가지 않았고 백업 절차를 업데이트해야 했습니다.

스테이징/프로덕션

셰익스피어는 오래 전에 "전 세계 모든 무대와 모든 남녀가 단순히 선수일 뿐입니다. 이 경우 단계는 스테이징에 관한 것이고 모든 엔터프라이즈 시스템의 핵심입니다. 시스템이 프로덕션 환경에 있으면 새 구성을 시도하고, 새 사용자 지정을 추가하고, 새 보고서, 링크, 필드 및 기타 변경 내용을 시도하려고 합니다. 업데이트 및 업그레이드가 있으며 이러한 모든 항목은 프로덕션 환경의 사용자에게 가해지기 전에 스테이징 또는 개발 환경에서 먼저 시도해야 합니다. 브라우저 업데이트 또는 데이터베이스 업데이트와 같은 기본 항목은 엔터프라이즈 시스템을 루프에 throw할 수 있으므로 프로덕션 환경과 별개인 스테이징 환경을 유지하고 유지 관리해야 합니다. 가상 서버의 시대와 시대에는 이전보다 더 쉬울 수 있습니다. 이제 프로덕션 시스템에서 전체 환경을 복제할 수 있지만 배포 방법에 따라 수행하는 것보다 더 쉬울 수 있습니다. 전체 서버를 복사한 경우에도 기술 퍼즐의 여러 부분을 참조할 수 있습니다.

모니터링, 모니터링, 모니터링

엔터프라이즈 시스템을 모니터링하는 데 사용할 수 있는 많은 감독 지점이 있습니다. 우선 최종 사용자가 Project Server를 사용할 수 있는지 확인하는 것이 중요하며, 사용할 수 없는 경우 적절한 기술 담당자에게 가능한 한 빨리 알림을 받도록 하는 것도 중요합니다. 고맙게도, 최종 사용자가 아직 문제를 발견하지 않은 경우에도 자동으로 기술 직원을 알릴 수있는 시스템이 작동하고 사용할 수 있는지 확인하기위한 시장에 많은 도구가 있습니다. 그러나 모니터링의 다른 측면도 중요합니다. 사용 중인 메모리 양, 사용 중인 CPU 양, 시스템이 자체에서 복구하더라도 보고했을 수 있는 오류, 필요한 서버 다시 시작, 기술 인프라의 다른 요소의 관련 상태 등 응용 프로그램의 상태 로그와 감시를 유지하는 것이 좋습니다. 예를 들어 IIS에 기술적인 문제가 있다는 것을 아는 것은 엔터프라이즈 애플리케이션의 가용성을 유지하는 데 매우 중요할 수 있습니다.

작은 변경 내용도 변경됩니다.

Project Server를 기반으로 하는 기술은 매일 변경됩니다. 이러한 모든 변경 내용을 피하는 것은 불가능합니다. Windows Server 운영 체제는 몇 주마다 업데이트를 받을 수 SQL Server 몇 일마다 업데이트를 수신하는 경우가 많습니다. 개별 Windows 클라이언트 운영 체제, 바이러스 스캐너, 방화벽 및 Internet Explorer 및 추가 기능은 정기적으로 업데이트를 받습니다. 데이터와 최종 사용자 간의 체인 부분은 애플리케이션이 중단될 수 있는 잠재적 지점이므로 전체 기술 스택에서 변경 내용을 관리하는 구조를 만듭니다.

여러 엔터프라이즈 애플리케이션이 스택의 유사한 측면에 따라 달라질 수 있으므로 이는 어려울 수 있습니다. 전체 SharePoint Server 환경이 중단되었음을 확인하기 위해 Project Server를 잠시 뒤로 업데이트한 클라이언트가 하나 있었습니다. 프로젝트 서버/SharePoint Server 업데이트가 적용된 방식에 오류가 분명히 있었습니다. 전체 백업이 있었고 데이터가 손실되지 않았지만 업그레이드 프로세스에는 즉각적인 롤백 프로비전이 없었기 때문에 반전하는 데 며칠이 걸렸기 때문에 그 효과는 파괴적이었습니다.

다른 조직에서는 회사에서 이미 사용 중인 다른 엔터프라이즈 애플리케이션이 최신 브라우저 버전을 지원하지 않는다는 것을 발견하기 위해 모든 사용자가 브라우저 버전을 업그레이드해야 한다는 것을 확인하기 위해 다른 엔터프라이즈 애플리케이션을 업데이트한 클라이언트가 있었습니다. 그것은 속담의 바위와 딱딱한 장소였다. 결국 엔터프라이즈 시스템의 업그레이드를 롤백하고 모든 엔터프라이즈 애플리케이션이 새 브라우저 업그레이드를 진행할 수 있을 때까지 기다려야 했습니다.

통합되는 것보다 통합된 것처럼 보이는 것이 더 좋은 경우도 있습니다.

판매 데모는 항상 여러 도구의 통합을 매우 쉽게 만듭니다. 이봐 프레스토, 데이터는 여기에서 시작하고 거기서 끝납니다! Project Server와 같은 매우 유연한 도구와 Finance/ERP와 같은 다른 엔터프라이즈 시스템 간의 연결을 설정하는 것은 충분히 힘든 작업이며, 링크가 설정되기 전에 두 시스템이 모두 프로덕션에 있고 안정적이어야 합니다. 그러나 일단 진행되면 두 시스템의 변경 내용을 모니터링하여 계속 제대로 연결되도록 하는 것이 더욱 중요합니다.

두 시스템을 업그레이드할 경우 데이터 변경, 구조 변경 또는 다른 기술 요구 사항이 있을 수 있습니다. 가능한 새로운 기능과 이점도 있을 수 있지만 프로덕션 환경에 출시되기 전에 스테이징 환경에서 기존 연결 기능을 테스트해야 합니다.

문서, 문서, 문서

Project Server가 선택되고 배포되었을 때 그곳에 있었던 사람들은 그 역할에 영원히 있지 않을 것입니다. 실제로 훌륭한 작업을 수행했다면 조직에 필요한 다음 엔터프라이즈 배포를 관리할 수 없습니다. 따라서 이러한 결정을 내리는 데 사용된 구성 결정, 예상 이점, 운영 기대치 및 매개 변수를 문서화하는 것이 필수적입니다. 미래에, 다른 사람들은이 시스템을보고 그들의 머리를 긁적 것입니다, "그들은 무엇을 생각하고 있었는가?" 당신이 그들에게 있는지 확인합니다.

엔터프라이즈 시스템 문서는 모든 업그레이드, 비즈니스 또는 기술 소유자의 각 변경, 운영 구조 또는 비즈니스 요구 사항의 주요 변경으로 업데이트되는 살아있는 문서여야 합니다.

도약하기 전에 살펴보기

그것은 우리가 처음으로 어두운 호수로 다이빙하는 사람들에게 주는 조언입니다. 얕은가요? 표면 바로 아래에 바위가 있습니까? Project Server와 같은 엔터프라이즈 프로젝트 관리 시스템은 실제로 복잡한 데이터 요소를 한 곳으로 가져올 수 있습니다. 여기서 해당 데이터를 기반으로 한 결정이 더 효과적일 수 있으며 이러한 결정의 이점은 조직에 큰 차이를 만들 수 있습니다. 하지만 이러한 혜택의 가치를 빠르게 없애줄 수 있는 비용과 위험에 조직을 노출하지 않고도 필요한 혜택을 얻을 수 있는 방식으로 엔터프라이즈 시스템을 운영할 수 있도록 숙제를 해야 합니다.

작성자 정보

Chris Vandersluis는 캐나다에 본사를 둔 HMS 소프트웨어인 Microsoft Certified Partner인 몬트리올의 사장 겸 설립자입니다. 그는 맥길 대학교에서 경제학 학위를 취득했으며 프로젝트 제어 시스템의 자동화 분야에서 30년 이상의 경험을 보유하고 있습니다. 그는 PMI(프로젝트 관리 연구소)의 오랜 회원이며 MPUG(Microsoft Project Users Group)의 몬트리올, 토론토 및 퀘벡 지부를 설립하는 데 도움을 주었습니다. Chris가 저술한 출판물에는 포춘, 헤비건설 뉴스, 컴퓨팅 캐나다 잡지, PMI의 PMNetwork 등이 있으며, 프로젝트 타임즈의 정기 칼럼니스트입니다. 그는 McGill 대학에서 고급 프로젝트 관리를 가르치고 종종 북아메리카 및 전 세계의 프로젝트 관리 협회 기능에서 연설합니다. HMS Software는 TimeControl 프로젝트 지향 시간 유지 시스템의 게시자이며 1995년부터 Microsoft 프로젝트 솔루션 파트너로 활동해 왔습니다.

Chris Vandersluis는 다음에서 전자 메일로 연락할 수 있습니다. chris.vandersluis@hms.ca

Chris Vandersluis에서 더 많은 EPM 관련 문서를 읽으려면 HMS의 EPM 지침 사이트(https://www.epmguidance.com/?page_id=39)를 참조하세요.