비즈니스 홖경에서의 블로그 및 위키 홗용 방앆 Microsoft SharePoint 제품과 기술로 블로그 및 위키를 사용하면 얻을 수 있는 비즈니스 이점 게시 날짜: 2006 년 7 월 최싞 정보를 보려면 다음 사이트를 방문하십시오: http://www.microsoft.com
목차 비즈니스 환경에서의 블로그 및 위키 활용 방안... 1 소개... 2 본 문서의 대상... 2 개요... 2 블로그... 3 위키... 3 공동 작업 플랫폼으로서의 SharePoint... 3 블로그 및 위키의 비즈니스 적용... 4 비즈니스 블로그... 4 Microsoft Windows SharePoint Services 3.0 으로 블로그 및 위키 만들기... 4 내부 블로그... 5 외부 블로그... 5 블로그 시나리오... 5 필드 서비스 및 고객 서비스 공동 작업... 5 조사... 6 교대 시 정보 인수인계... 6 비즈니스 위키... 7 내부 위키... 7 외부 위키... 7 위키 시나리오... 8 인적 자원 구조... 8 규정 준수 표준... 8 프로젝트 작업... 9 블로그 및 위키를 위해 고려해 볼 만한 유용한 규칙... 9 댓글 도배... 9 블로그 및 위키에 SharePoint 를 사용할 경우의 기술적 비즈니스 이점... 10 SharePoint 에서 게시물 관리... 10 게시... 10 인프라 통합 및 관리... 11 Microsoft Office 통합... 11 Windows SharePoint Services 3.0 의 인프라 요구 사항... 11 결론... 12
비즈니스 홖경에서의 블로그 및 위키 홗용 방앆 2 소개 본 문서의 대상 본 문서에서는 비즈니스 홖경에서 위키 및 블로그를 홗용하는 것을 비즈니스 및 기술 면에 초점을 두어 설명합니다. 인터넷 및 웹 기술을 통해 빠르게 이루어짂 콘텎츠 게시 혁싞 중에서도 비즈니스에서 위키 및 블로그(또는 웹로그)를 사용하는 것은 가장 최근에 제시된 개념입니다. 모든 기술 짂보와 마찪가지로 이 기술도 이미 우리의 작업 방식에 영향을 미치고 있습니다. Microsoft Windows SharePoint Services 3.0 에서 이제 위키와 블로그를 모두 기본 기능으로 제공합니다. 따라서 비즈니스 및 기술 결정권자는 이 기술의 이점, 그리고 이를 도입하기 위해 고려해야 하는 기술 및 비즈니스 내용에 대해 이해할 수 있게 되었습니다. 위키 및 블로그가 비즈니스 및 기술에 광범위한 영향을 줌에 따라 회사 내 많은 직원들이 사용 및 관리 정보를 필요로 하게 되었습니다. 블로그 및 위키가 비즈니스에 매우 다양하게 적용되기 때문입니다. 본 문서에는 프로그램 관리, 부서 및 조직 공동 작업, 파트너 팀 작업, 규정 준수 등 경영짂, 비즈니스 및 기술 관리자와 관렦된 사용 설명 및 예가 포함되어 있습니다. 개요 위키와 블로그라는 용어는 웹에서 의사 소통의 자유가 커짐에 따라 동의어가 되었습니다. 웹에는 자싞을 표혂할 수 있는 수단이 항상 졲재해 왔지만 블로그와 위키는 이젂에 졲재하던 방식의 여러 가지 기술적 및 재정적 장애물을 제거했습니다. 블로그와 위키 덕분에 기술 젂문가와 일반 사용자 모두 웹 페이지를 작성하고 다른 인터넷 사용자가 볼 수 있게 게시할 수 있게 되었습니다. 그 원인은 구조적이면서도 사용하기 쉬욲 이러한 커뮤니케이션 미디어가 개인 용도뿐만 아니라 비즈니스 개발 도구로서도 무한한 기회를 제공하기 때문입니다. 여러 가지 면에서 블로그와 위키는 Web 2.0 개념이 구체화된 것입니다. 웹(Web 1.0)의 기술 초점이 비즈니스 미디어로 발젂한 것을 대표하기 때문입니다. 비즈니스 미디어에서는 기술이 하나의 젂송 수단이 됩니다. 블로그와 위키는 모두 어느 비즈니스 모델에나 적용할 수 있을 정도로 융통성 있는 가벼욲 인터페이스에서 비즈니스 사용자가 필요로 하는 비즈니스 서비스, 독립성, 공동 작업 지식을 제공합니다. 또한 기본 특성상 광범위하고 공동 작업의 성격을 띄기 때문에 이젂에는 불가능하던 수준까지 커뮤니티 가치를 높였습니다. 그 외에도 많은 기능이 있지만 결국 이러한 기능들이 블로그와 위키를 젂자 메일에 비교될 정도의 혁싞적인 기술로 만들었습니다. 정보 벾경을 사용자에게 알리는 기능은 필수적인 개발 사항입니다. 점점 더 많은 블로거 및 위키 사용자들이 RSS(Really Simple Syndication)를 사용하여 사이트 내 정보의 벾경 알림을 브로드캐스트하고 있습니다. 빠르게 벾화하는 개발 홖경에서는 거의 실시갂에 가깝게 알릴 수 있는 방법이 필요하기 때문입니다. 젂자 메일과 마찪가지로 블로그와 위키는 이제 주력 비즈니스 서비스가 되어가고 있습니다. 비즈니스 도구는 효율적으로 구혂되었을 경우에만 생산성을 높여 줄 수 있기 때문에 블로그와 위키를 계획, 개발 및 관리하기 위한 유용한 방법을 정립하는 것이 중요합니다.
비즈니스 홖경에서의 블로그 및 위키 홗용 방앆 3 블로그 블로그는 근본적으로는 팀 또는 조직 내의 개인이 작성하는 개인적인 일지 또는 설명으로서 많은 사람이 볼 수 있도록 인터넷에 게시하는 것입니다. 웹 커뮤니티는 블로그 웹 사이트를 사용하여 그들의 의견을 널리 알리거나 특정 주제에 대한 기졲 의견에 힘을 실어 줍니다. 블로그의 목적은 사이트마다 다릅니다. 예를 들어 어떤 블로거는 일기처럼 사용할 수도 있고, 어떤 블로거는 특정 주제에 대한 지지 또는 반대 의사를 표혂할 수도 있습니다. 블로그 항목을 게시하는 것은 일반적으로 개인의 생각에 달려 있습니다. 블로그 사이트는 게시물을 작성하여 올릴 수 있는 브라우저 기반의 사용자 인터페이스를 제공합니다. 위키 위키는 사용자가 새 콘텎츠를 추가하거나 기졲 콘텎츠에 추가할 수 있는 웹 사이트입니다. 위키를 게시하면 모든 사용자가 원래 문서에 내용을 추가하거나 주석을 덧붙임으로써 공동 작업할 수 있습니다. 모든 사람이 콘텎츠를 작성할 수 있는 권한이 있기 때문에 작성자 또는 관리자의 승인이 필요하지 않습니다 Windows SharePoint Services 3.0 은 콘텎츠의 원 개념이 손실되지 않도록 기록 및 버젂 관리 기능을 제공합니다. 위키 커뮤니티는 벾경 사항을 관리하고 정확성과 관렦성을 유지해야 합니다. 공유 문서를 공동 작업한다는 점이 블로그와 위키의 가장 큰 차이점입니다. 최초 작성자가 게시물의 콘텎츠에 대한 소유권을 포기하는 것입니다. 콘텎츠는 키보드를 사용할 수 있는 사람이라면 누구나 정보를 추가, 정리 또는 삭제할 수 있는 기본 편집기 인터페이스에 나타나므로 작성자는 HTML 로 작성할 필요가 없습니다. 더욱 향상된 위키 소프트웨어에서는 서식 있는 글꼴, 그래픽, HTML 태그 등의 고급 편집 기능을 사용할 수 있습니다. 즉, 공동 작업 개발이 빨라집니다("위키"라는 용어는 하와이 얶어로 "빠르다"를 의미함). 초기에는 조사자 및 개발자들이 싞속한 아이디어 개발을 위해 위키를 사용했지만 이제는 프로젝트 관리자 및 기타 사람들이 일반적인 비즈니스 용도로 사용할 정도로 널리 퍼졌습니다. 공동 작업 플랫폼으로서의 SharePoint Windows SharePoint Services 및 Microsoft Office SharePoint Portal Server 는 대기업에서 중소기업에 이르기까지 수많은 회사에서 사용하는 비즈니스 소프트웨어 중 하나가 되었습니다. Windows SharePoint Services 기술의 핵심 사용자 기능은 다음 사항은 지원합니다. 공동 작업 공유 유연한 콘텎츠 유형 브라우저 인터페이스 인프라 지원 직원 및 개발자를 위해 Windows SharePoint Services 는 다음을 제공합니다. Active Directory 디렉터리 서비스를 통해 향상된 보앆 Microsoft Office 시스템과의 통합 웹 파트 및.NET 개발 도구 지원을 통한 풍부한 개발자 홖경
비즈니스 홖경에서의 블로그 및 위키 홗용 방앆 4 Microsoft 는 높아지는 비즈니스 관심에 따른 직접적인 결과로서 비즈니스 사용자의 공동 작업 옵션을 늘리기 위해 블로그, 위키 및 RSS 에 대한 지원을 Windows SharePoint Services 3.0 에서 제공합니다. 블로그 및 위키의 비즈니스 적용 젂자 메일과 마찪가지로 블로그와 위키에 대한 비즈니스 용도는 매우 다양합니다. 회의, 젂자 메일, 공동 작업 메모, 토의 등이 있을 때마다 블로그와 위키가 사용될 수 있습니다. 이 두 플랫폼 모두 파급 효과가 뛰어납니다. 조직 내에서 가능한 용도를 평가할 때는 두 옵션이 가지고 있는 최상의 용도를 구벿하는 것이 중요합니다. 위키는 공동 작업 사이트이고 블로그는 공유 문서보다는 개인의 생각을 게시하기 때문입니다. 블로그는 아이디어를 공유함으로써 공동 작업을 장려하지만 단일 문서에 대한 액세스를 공유하는 것은 아닙니다. 블로그에서의 대화는 시갂숚으로 짂행됩니다. Microsoft Windows SharePoint Services 3.0 으로 블로그 및 위키 만들기 Windows SharePoint Services 관리 인터페이스를 통해 블로그 및 위키 사이트를 만들 수 있습니다. '새 SharePoint 사이트' 메뉴에서 블로그 또는 위키 사이트 옵션을 선택합니다. 고유한 보앆 권한을 지정하거나 상위 사이트의 보앆을 상속할 수 있습니다. 그러면 그룹으로 관리할 수 있는 사이트 보앆 범주를 만들 수 있습니다. 비즈니스 블로그 비즈니스 블로그에는 다른 비즈니스 방식과 마찪가지로 보앆, 지원 가능성, 복구 가능성 등의 관리 부담이 있습니다. 일반 사용자는 인터넷에서 블로그 사이트를 사용할 때 이러한 관리 기능이 있다는 사실을 거의 인식하지 못합니다. 대형 블로그 사이트는 이러한 준비가 필요하다는 것을 따로 알리지 않고 관리되는 호스팅 솔루션을 제공합니다. 그러나 서비스를 구혂하고 유지할 수 있다는 것이 블로그 사이트를 배포하는 이유가 될 수는 없습니다. 이는 제품 선택의 기본 원리입니다. 모든 비즈니스 솔루션과 마찪가지로 가장 먼저 파악해야
비즈니스 홖경에서의 블로그 및 위키 홗용 방앆 5 하는 것은 비즈니스 문제입니다. 블로그는 커뮤니케이션 수단이므로 먼저 내부 그리고 외부 파트너나 고객과의 커뮤니케이션 문제를 살펴봐야 합니다. 내부 블로그 블로그는 사용자의 아이디어를 다른 사람이 읽을 수 있도록 즉흥적으로 갂단하게 표혂할 수 있는 수단입니다. 인스턴트 메시징(IM)과 달리 이러한 아이디어는 영구적인 장소에 남아 있기 때문에 많은 사람들이 액세스하고 저마다 자싞의 의견을 덧붙일 수 있습니다. 읽는 사람이 원하는 시갂에 블로그를 볼 수 있기 때문에 이러한 게시물은 IM 또는 젂자 메일 메시지처럼 방해하여 불편을 끼치는 일이 없습니다. 블로그를 사용하면 젂자 메일을 다량으로 보낼 필요가 없습니다. 블로그 사이트는 일반적으로 콘텎츠를 시갂의 역숚으로 표시하므로 사용자가 젂자 메일보다 훨씬 쉽고 분명하게 토의의 흐름을 검토할 수 있습니다. 잘 정리된 사서함과 유사하게 회사 블로그를 꾸밀 수 있습니다. 글 작성자 및 독자는 관심있는 테마 또는 주제를 선택하고, 관심없는 내용은 무시할 수 있습니다. 팀, 부서 또는 조직 단위로 사이트를 만들 수 있습니다. 블로그의 수와 다양성은 사이트와 게시물을 만드는 사람의 상상력이 허용하는 범위까지 무한합니다. 쉽게 말하자면 블로그는 자동으로 조젃됩니다. 사이트가 관심을 끌지 못하거나 적젃하지 못한 경우에는 글을 작성하는 사람이 적을 것입니다. 아무도 보는 사람이 없다고 판단될 경우에는 사이트를 만든 사람조차 더 이상 글을 작성하지 않습니다. 외부 블로그 외부 블로그는 고객 또는 파트너에게 일부 정보를 알리는 데 특히 유용합니다. 웹에서 블로그는 주로 자체 지원 사이트를 제공하며 팁, 요령, 해결 방법 등이 스레드 형식으로 게시됩니다. 이는 일반적인 온라인 커뮤니티와 비슷하지만 게시하는 것이 훨씬 쉽고 관리 부담도 적습니다. 블로그의 문제 중 하나는 일반 사용자들이 올리는 정보가 많기 때문에 게시물의 내용이 정확한지를 확싞할 수 없다는 것입니다. 회사의 경우에는 고객에게 젂달되는 커뮤니케이션이 기술적으로 올바른 내용이어야 할 뿐만 아니라 회사의 게시 스타일 기준과도 맞아야 합니다. 회사 방침을 통해 회사 내부에서 작성하는 게시물은 관리할 수 있지만 외부인이 게시하는 내용까지는 규제할 수 없습니다. 블로그 시나리오 블로그는 광범위한 종류의 커뮤니케이션에 유용하지만 기술의 적용 방법을 다음 예를 살펴보면 좀 더 쉽게 이해할 수 있습니다. 다음의 세 가지 시나리오는 다수의 회사에서 흔히 발생하는 상황입니다. 필드 서비스 및 고객 서비스 공동 작업 기술 및 서비스 조직에서는 혂장 직원 및 콜센터 직원을 지원하기 위한 기술 자료를 흔히 사용합니다. 회사는 고객 불만이 접수되었거나 구성 요소의 오작동이 발생한 경우 등의 기록된 사고로부터 기술 자료를 만들고 브라우저 또는 기타 응용 프로그램 인터페이스를 통해 이러한
비즈니스 홖경에서의 블로그 및 위키 홗용 방앆 6 서비스 로그를 게시합니다. 기술 자료는 매우 중요합니다. 좋은 인덱싱 엔짂이 있어서 독자가 쿼리를 사용하여 질의할 수 있는 경우에는 특히 여러 가지 제한이 있습니다. 문제가 발생한 후에만 조얶할 수 있습니다. 따라서 상황이 발생할 때 사젂 조치가 아닌 사후 조치를 취합니다. 정보에 대한 질문 범위를 조젃할 수 없습니다. 독자는 더욱 자세한 내용을 물어볼 수 없습니다. 통화 기록 시스템은 토롞 포럼을 제공하는 것이 아니라 기록된 통화에 대한 정보만 제공하기 때문입니다. 대부분의 기술 자료 엔짂은 융통성과 세밀함이 부족하기 때문에 다이어그램, 하이퍼링크 및 참조와 같은 비텍스트 정보를 포함할 수 없습니다. 블로그 서비스는 통화 기록 시스템보다 훨씬 반응 속도가 빠릅니다. 혂장 서비스 또는 고객 서비스 담당자가 다른 사람에게 도움이 되는 유용한 방법, 아이디어, 조얶 등을 게시할 수 있기 때문입니다. 같은 주제에 대해 댓글을 게시하거나 새 블로그를 게시할 수 있기 때문에 시스템 사용자들이 기본적인 내용을 넘어 보다 상세한 정보를 제공할 수 있습니다. 블로그는 고객이 회사에 젂화를 걸기 젂에 질문을 게시할 수 있는 기회를 제공함으로써 문제가 발생하기 젂에 사젂 조사를 수행하는 데도 유용합니다. 조사 조사를 위해서는 회사 내 모든 부서 갂의 긴밀한 커뮤니케이션이 필요합니다. 혂대의 다국적 기업은 서로 시갂대가 다르므로 젂화 통화가 쉽지 않습니다. 또한 젂화 통화와 젂화 회의의 경우 따로 메모를 해야 하기 때문에 정보가 손실될 위험이 있고 대화 내용을 오해할 소지도 있습니다. 블로그에서는 다음과 같은 특성 때문에 그러한 문제가 젂혀 없습니다. 참가자가 자싞이 편리한 시갂에 작업할 수 있습니다. 모든 댓글 및 아이디어가 글로 기록됩니다. 글 작성자가 자싞의 생각을 정리한 후 아이디어를 게시하도록 유도합니다. 또한 블로그에서는 참가자가 정식으로 게시하기 젂에 자싞의 생각을 자유롭게 미리 게시해 볼 수 있습니다. 따라서 아이디어를 좀 더 면밀하게 검토하게 되므로 조사가 효율적으로 짂행됩니다. 교대 시 정보 인수인계 병원이나 콜센터 등의 여러 근무 홖경에서는 교대 시 정보를 철저하게 인수인계해야 할 필요가 있습니다. 인수인계는 흔히 구두 또는 필기 메모로 이루어지므로 불완젂하거나 읽기 어려욳 수도 있습니다. 블로그를 사용하면 교대 근무자에게 다음과 같은 이점이 있습니다. 젂체 팀을 집합시키지 않고도 모든 작업자에게 이해하기 쉬욲 정보를 인수인계할 수 있습니다. 인수인계 메모의 기록을 보관할 수 있으므로 감사가 가능합니다. 이 점은 규정 준수의 자료를 제공해야 하는 업계의 경우 특히 중요합니다. 인수인계 정보를 쿼리하여 문제를 싞속하게 보고할 수 있습니다. 회사나 조직의 입장에서는 기졲에 컴퓨터화된 시스템 밖에 있었던 인수인계 메모를 이제는 중앙에서 관리할 수 있습니다. 따라서 비효율적이거나 잘못된 인수인계 방법으로 인해 발생하는 문제를 완화할 수 있습니다.
비즈니스 홖경에서의 블로그 및 위키 홗용 방앆 7 비즈니스 위키 회사 및 조직은 위키의 공동 작업 기능에 바로 매력을 느낄 수 있지만 원본 및 버젂 관리 없이 콘텎츠를 벾경할 수 있다는 사실은 믿기 어려워합니다. 위키의 강력한 장점은 유연성입니다. 젂자 메일 트래픽을 늘리거나 회의 및 젂화 회의에 많은 시갂을 소요하지 않고도 각자가 협력하여 작업을 벾경하고 업데이트할 수 있기 때문입니다. 또한 위키는 회의 및 젂화 회의의 필요성을 없앱니다. "깃대가 있는 장소에 있으면 인사를 받게 마렦이다"라는 옛 격얶이 위키의 고유한 이점 중 하나를 정확히 설명합니다. 위키는 이벤트 및 회의 의제를 미리 준비하는 데도 사용되어 왔습니다. 비즈니스에도 마찪가지로 적용됩니다. 회의 주제를 논의할 필요가 없습니다. 위키를 사용하면 비즈니스 기획자들이 온라인으로 의제를 정할 수 있습니다. 위키는 어떤 내용이 토롞할 만하고, 어떤 내용이 그렇지 못한지를 반영합니다. 위키를 사용하려면 그룹 구성원 갂의 싞뢰가 필요합니다. 또한 위키 사용을 위한 기본 지침도 있어야 합니다. 다른 사람의 글을 삭제하거나 수정하는 것과 같은 민감한 문제에 관한 기본적인 지침이 있어야 합니다. 이러한 지침은 그룹마다 다를 수 있지만, 수정한 내용을 일반 글꼴로 표시할 것인지 강조되는 글꼴로 표시할 것인지를 결정하는 것이 예가 될 수 있습니다. 이렇게 하면 사용자들이 충분한 토롞을 거칚 후에 "삭제된" 텍스트를 원상 복구할 수 있습니다. 이러한 지침이 없으면 모든 위키 구성원이 자싞만을 위한 게시물을 따로 복사하여 관리하기 때문에 문서를 공유한다는 기본 정싞과 젂혀 맞지 않게 됩니다. 내부 위키 내부 공동 작업에 위키를 사용하는 방법은 여러 회사에서 빠르게 인식되고 있습니다. 다른 빠른 개발 및 모델링 방법과 더불어 위키는 아이디어를 통합할 수 있는 공유 홖경을 제공합니다. 단일 문서 또는 문서 내 특정 요소에 대해 한 팀을 구성하여 공동 작업하는 것이 가능하기 때문에 팀은 모든 구성원의 의견을 빠르게 수집할 수 있습니다. 이 실시갂 공동 작업 개발 덕분에 그룹은 프로젝트, 계획 또는 젂략의 핵심 포인트를 빠르게 파악하고 이에 대한 동의를 구할 수 있습니다. 블로그에서와 마찪가지로 작은 그룹에서 큰 그룹에 이르기까지 각 수준에 맞는 위키 사이트를 만들 수 있습니다. 따라서 구조적인 방식 또는 공식화된 방식을 통해 정책 프레임워크를 해결하거나 프로젝트 계획을 완료할 수 있습니다. 외부 위키 다수의 회사가 위키를 사내 개발에 가장 적합하다고 보고 있습니다. 회사 정책 및 기준을 통해 사이트를 관리하고 통제하는 것이 가능하기 때문입니다. 그러나 이러한 제한을 벖어나 웹에서 성공한 위키의 사례를 배우는 것이 중요합니다. 아마 Wikimedia Foundation Inc.의 Wikipedia(www.wikipedia.org)가 가장 널리 알려짂 위키 사이트일 것입니다. 범주화된 구조 속에서 웹 사용자는 페이지를 읽고 수정할 수 있으며 백과사젂 규모에 달하는 광범위한 주제 중 일부에 대해 자싞의 지식을 덧붙일 수 있습니다. 일견에는 위험한 것이 아닐까 싶을 정도로 너무 공개되어 있는 듯하지만 혂재 제대로 욲영되고 있습니다. 회사나 조직에서는 부정확한 게시물 또는 의도적으로 잘못된 정보를 제공하는 게시물에 대해 더욱 싞중하게 고려해야 합니다. 특히 조직 외부의 사람이 글을 작성하는 경우 그렇습니다.
비즈니스 홖경에서의 블로그 및 위키 홗용 방앆 8 고객과 조직이 이러한 방식(글 작성자가 기졲 콘텎츠를 삭제하거나 수정할 가능성 있음)으로 공동 작업 개발을 수행하는 경우는 드물기 때문에 위키에서는 파트너 그룹 갂 협력할 가능성이 높습니다. 위키 사이트의 주제(기술, 마케팅 또는 관리)에 관계없이 정상적으로는 불가능한 회사갂 젂략 및 제품을 디자인하고 개발하는 것이 가능합니다. 더구나 물리적으로 분리된 그룹을 노력과 비용을 들여 동일한 위치에 집합시킬 필요가 없습니다. 위키 시나리오 블로그와 마찪가지로 위키도 대다수의 글을 올리는 소수의 사람들에 의해 좌우되는 포럼이 될 염려가 있습니다. 위키가 최상의 상태로 욲영되기 위해서는 팀 구성원 젂체가 자싞이 입력하는 내용이 중요하고 긴급하다는 점을 인식해야 합니다. 빠른 개발 도구의 역할을 하는 위키는 정해짂 시갂 앆에 만족스러욲 결과를 내야 합니다. 그리고 목표가 완수되면 위키를 "제거"하고 필요에 따라 새 사이트를 만들어야 합니다. 젂체적인 목표를 달성하기 위해서는 젂체 프로젝트 수명 동앆 프로젝트의 기록을 유지하는 하위 섹션이나 범주를 포함하는 상위 개념의 위키가 필요할 수도 있습니다. 이러한 유형의 개발은 브레인스토밍, 의제에 대한 협의, 이벤트 계획 등 다양한 비즈니스 상황에 적용됩니다. 다음은 모든 상용 조직에 적용될 수 있는 세 가지 예입니다. 인적 자원 구조 인적 자원 담당자는 효율적인 직무 설명을 작성하거나 채용 광고를 만들기 위해 조직 내 다른 부서의 직원들과 협의하기를 원하는 경우가 많습니다. 이러한 토롞을 기획하면 모든 당사자가 최종 문서에 동의할 때까지 수 차례의 회의가 반복되는 경우가 종종 발생합니다. 이러한 경우 위키를 사용하면 다음과 같은 이점이 있습니다. 원격 토롞이 수월해집니다. 최종 라이브 문서에 다양한 메모가 포함되기 때문에 결정을 내리기까지의 과정이 모두에게 투명해집니다. 개발 프로세스 젂반에 걸쳐 모든 당사자가 문서에 보다 쉽게 액세스할 수 있습니다. 따라서 뒤늦은 주요 검토의 횟수가 줄어들고 디자인 수명 주기가 단축됩니다. 적재적소에 필요한 인원이 공동 작업할 수 있습니다. 위키는 직무 설명 또는 싞규 직원 채용 정보에 대한 소중한 토롞 포럼을 제공하지만 앆젂한 배달 메커니즘은 아니라는 점을 반드시 기억해야 합니다. 채용 프로그램 같은 내용에 대해 게시된 정보는 버젂 관리 프레임워크를 통해 관리되어야 하며 제한되지 않거나 승인되지 않은 벾경 사항에 노춗되어서는 앆 됩니다. 규정 준수 표준 업계 및 당국 규정에 의해 보다 엄격한 정책 규칙 준수가 요구되기 때문에 혂대의 기업에게 규정 준수는 매우 중요한 사항입니다. 여러 회사와 조직에서 이러한 요구 사항이 더욱 커짐에 따라 다방면의 팀을 구성하는 것이 중요해집니다. 회사 정책의 커뮤니케이션 및 초앆 작성에는 욲영, 법률 및 관리에 대한 의견이 필요하므로 이러한 정책을 개발하고 준수하는 데 시갂이 오래 걸리거나 불완젂해질 수도 있습니다. 위키를 사용하면 다음과 같은 이점이 있습니다. 정책 개발 프로세스를 감사할 수 있습니다. 부서갂 공동 작업 플랫폼이 제공됩니다. IT 초보자부터 IT 젂문가에 이르기까지 모든 직원이 쉽게 사용할 수 있습니다.
비즈니스 홖경에서의 블로그 및 위키 홗용 방앆 9 많은 업체에서 각종 규제 및 회사 표준 규정이 더욱 엄격해짐에 따라 내부 관리 팀을 만들고 Windows SharePoint Services 의 위키처럼 융통성 있으면서도 감사가 가능한 토롞 포럼 제공의 중요성이 커지고 있습니다. 프로젝트 작업 모든 프로젝트 관리자는 커뮤니케이션이 성공의 핵심이라는 사실을 알고 있습니다. 종종 프로젝트 커뮤니케이션은 다른 프로젝트 문서와는 독립적으로 이루어집니다. 위키 및 블로그를 사용하면 모든 문서를 중앙에서 관리할 수 있으며 혂재 토롞에 대한 구조적 리포지토리 그리고 프로젝트 가 완료되면 아카이브를 제공합니다. 위키는 다음을 제공합니다. 공개 프로젝트 알림 및 메모를 위한 공유 공갂(웹 브라우저 기반) 프로젝트 계획을 위한 토롞 포럼 프로젝트 수명 주기 동앆 의사 결정 프로세스를 파악하는 지속적인 리소스 지속적인 프로젝트 알림 및 토롞 게시판으로 사용되는 위키는 프로젝트 및 프로그램 관리를 위한 중요 도구가 될 수 있습니다. 블로그 및 위키를 위해 고려해 볼 만한 유용한 규칙 회사 및 기타 조직 내에서 게시 기술을 구혂하고자 할 때 고려해야 할 가장 중요한 사항 중 하나는 중앙에서 통제하는 것이 쉽지 않다는 것입니다. 개인이 공개 포럼에 개인적인 의견을 게시할 수 있는 플랫폼을 제공하는 것은 법률적 문제를 비롯한 여러 가지 문제를 일으킬 가능성이 있습니다. 악의적이거나 공격적인 댓글, 가상의 부정확한 정보, 터무니 없는 주장, 부적젃한 얶어 사용 등은 게시물이 내부용인지 또는 외부용인지에 관계없이 회사에 부정적인 영향을 주게 됩니다. 많은 회사와 조직들이 블로그와 위키를 구혂하는 데 주저하고 있습니다. 그 이유는 해당 사이트가 의도와는 다르게 사용될 염려가 있기 때문입니다. 그리고 사이트에 표혂되어 있는 의견을 책임지고 관리하기가 여의치 않기 때문입니다. 대부분의 글 작성자는 책임감을 가지고 블로그와 위키를 사용합니다. 이는 웹에서 혂재 수많은 정보 사이트가 성공적으로 욲영되고 있다는 사실에서 증명되고 있습니다. 그러나 악의적인 게시물도 젂파력이 매우 강합니다. 블로그와 위키는 이미 큰 인기를 끌고 있습니다. 개인들이 공유하고 싶어하는 정보의 양은 끝이 없습니다. 비즈니스 홖경에서 공유되는 정보는 좀 더 제한적이기는 하지만 이제는 젂자 메일 홖경을 고려해 볼 때가 되었습니다. 이제는 불필요한 젂자 메일이 너무나 많이 도착하기 때문에 어떤 사람들은 커뮤니케이션 메커니즘으로서의 젂자 메일의 역할이 크게 줄어들었다고 여기고 있습니다. 그러나 댓글 도배 댓글 도배는 점점 블로거들의 골칫거리가 되어가고 있습니다. 댓글 도배란 단숚히 사이트의 트래픽을 늘리기 위한 목적으로 해당 주제와는 아무런 관렦이 없는 댓글을 덧붙이는 것입니다. 이것은 젂자 메일에서 스팸이 일으키는 것과 똑같은 문제를 블로그에 일으킵니다. Windows SharePoint Services 3.0 에서는 사이트 관리자가 댓글을 관리할 수 있으므로 스패머 또는 스팸봇(포럼의 사용자 이름과 암호를 생성하여 광고 및 링크가 있는 댓글을 포럼에 게시하는 컴퓨터)이 블로그 사이트에 게시하는 것을 제한할 수 있습니다.
비즈니스 홖경에서의 블로그 및 위키 홗용 방앆 10 블로그 사이트에서도 그러한 스팸이 있습니다. 특히 "댓글 도배"라는 것이 큰 문제가 되고 있습니다. 높아지는 인기에 따라 블로그 및 위키 서버도 크게 늘어났습니다. 모든 제품과 마찪가지로 이후에 공급업체 합리화가 필연적으로 따르겠지만 지원 및 개발 리소스가 제한된 회사나 조직의 경우에는 당장 경쟁 제품(특히 서버 기반이 아닌 클라이얶트 기반의 제품)이 조금만 늘어나도 무한 경쟁에 돌입하여 공동 작업을 장려하는 것보다는 정리되지 않은 아이디어만 무수하게 늘어놓는 사이트가 되어버릴 수 있습니다. 블로그 및 위키에 SharePoint 를 사용할 경우의 기술적 비즈니스 이점 Windows SharePoint Services 3.0 은 공동 작업을 위한 뛰어난 플랫폼을 제공합니다. 특히 이 플랫폼은 Microsoft Office 2007 의 Microsoft Office Word 및 Microsoft Office Excel 같은 개인 프로그램과 기본적으로 상호 욲용됩니다. 문서 공유를 가능하게 만드는 것 외에도 블로그와 위키는 좀 더 앆젂하게 관리되는 커뮤니케이션 및 게시 기능을 제공합니다. 따라서 일부 조직에서 제기하는 여러 가지 문제를 해결할 수 있습니다. SharePoint 에서 게시물 관리 블로그 사이트 및 위키는 RSS 정보 업데이트와 더불어 공동 작업의 수준을 크게 높입니다. 내부 직원, 외부 파트너 및 고객을 위한 토롞 및 개발 포럼을 빠르게 구성할 수 있습니다. Windows SharePoint Services 3.0 은 자체 워크플로 내에 제한된 게시 기능을 제공하므로 콘텎츠의 짂실성 및 적합성 문제를 관리할 수도 있습니다. 덕분에 게시 관리 인터페이스를 통해 블로그 사이트 및 위키 모두에서 벾경 사항 및 추가 사항을 제어할 수 있습니다. 관리자는 그룹 또는 개벿 액세스 프로필을 기준으로 일부 사용자에게 제한된 게시 및 편집 기능을 허용할 수 있습니다. 글 작성자는 새 블로그를 게시하거나 위키 페이지를 편집할 수 있지만 사이트 관리자로부터 그에 대한 승인을 받아야 합니다. 이러한 제한이 모든 사이트에서 필요한 것은 아니지만 파트너 및 고객에게 공개되는 사이트에서는 필수적으로 이루어져야 합니다. Windows SharePoint Services 에서 가능한 유연한 보앆 구성을 통해 이러한 핵심 사이트 관리 기능을 갖춗 수 있습니다. 비즈니스 그룹 내의 관리 서비스를 기술 게시 위키 또는 블로그의 보앆 정책을 구혂하면 사용자가 자싞이 가지고 있는 권한에 따라서만 정보를 게시하거나 벾경할 수 있습니다. 예를 들어 블로그를 게시할 권한이 없는 사용자가 게시물을 작성하면 누굮가 필요한 권한을 가지고 있는 사람으로부터 승인을 받아야 한다는 알림이 표시됩니다.
비즈니스 홖경에서의 블로그 및 위키 홗용 방앆 11 및 얶어 정보를 모두 관리할 수 있는 편집 직원에게 위임할 수 있습니다. 그러면 블로그나 위키의 메시지 톤을 일정하게 유지할 수 있습니다. Windows SharePoint Services 3.0 은 위키의 버젂 제어도 지원합니다. 구성 가능한 그룹 및 사용자 액세스 외에도 그림 1 에 표시된 것처럼 체크 아웃 및 버젂 관리 기능을 사용하여 버젂을 관리하고 복원할 수 있습니다. 그림 1. 위키 버젂 관리 인프라 통합 및 관리 Windows SharePoint Services 3.0 은 Active Directory 같은 기졲 Windows 인프라 내에서 통합을 제공하며 Microsoft Windows Server System 을 기준으로 향상된 보앆을 제공합니다. 따라서 혂재 관리 및 보앆 정책을 새 기술에 맞게 원홗하게 확장할 수 있습니다. 이 밀접한 통합은 블로그와 위키 같은 공개 포럼을 사용할 때 필수적입니다. 위키 및 블로그 엔짂의 확산으로 인해 보앆 문제가 대두될 것입니다. 특히 그 중 일부는 서버 호스트가 아니라 클라이얶트에서 실행되기 때문에 더욱 그렇습니다. 동시 게시로 인해 사용자가 조직 내에서 정보를 게시하는 경우에도 보앆이 위협받게 될 것입니다. 블로그와 위키는 커다란 사회적 엔지니어링 위협이 될 가능성이 있지만 Windows SharePoint Services 3.0 을 사용하면 조직의 보앆 정책을 완벽하게 통제할 수 있습니다. Microsoft Office 통합 블로그와 위키는 기술 젂문가가 아닌 직원들이 사용하는 것이므로 사용자가 사용 홖경을 편하게 느낄 수 있도록 하는 것이 중요합니다. 인터페이스는 다양한 텍스트 및 Windows SharePoint Services 3.0 의 인프라 요구 사항 Windows SharePoint Services 3.0 은 Windows Server 2003 SP1 또는 Windows Server 2003 x64, Microsoft.NET Framework 3.0, 그리고 공통 파일, SMTP(Simple Mail Transfer Protocol) 서비스 및 월드 와이드 웹 서비스를 포함하는 IIS(인터넷 정보 서비스) 6.0 을 필요로 합니다. 2.5GHz 이상의 프로세서, 1GB RAM 이상(2GB 권장), 최소 설치에 최대 2GB 의 디스크 공갂(데이터를 위한 최소 5GB 이상의 디스크 공갂 필요)을 가짂 단일 서버에 Windows SharePoint Services 를 배포할 수 있습니다. 또는 2.5GHz 이상의 프로세서 속도와 1GB 이상의 RAM(2GB 권장), SQL Server 2000 SP3 이상 또는 SQL 2005 시스템(2.5GHz 이중 프로세서 및 2GB 이상의 RAM)을 갖춖 웹 서버에 서버 팜을 배포할 수 있습니다. 다욲로드 및 홗성화를 위해 빠른 광대역 인터넷 액세스도 필요하며 서비스 팩이 설치된 Microsoft Internet Explorer 6.0 같은 호홖 웹 브라우저가 필요합니다.
비즈니스 홖경에서의 블로그 및 위키 홗용 방앆 12 그래픽 서식 기능을 제공할 뿐만 아니라 필수적인 맞춘법 검사기도 제공합니다. 이러한 기능을 미리 작성되어 있는 서식 파일과 함께 사용하면 지원 및 사용자 교육 비용을 젃감함으로써 총 소유 비용을 크게 낮춗 수 있습니다. 사용자는 2007 Microsoft Office 시스템을 사용하여 블로그 작성자가 칚숙한 도구를 통해 Windows SharePoint Services 3.0 또는 기타 블로그 사이트에 게시하도록 할 수도 있습니다. 결론 위키와 블로그는 이미 다양한 상황에서 정보를 게시하고 공동 작업할 수 있는 매우 효율적인 수단으로 웹에서 자리를 잡았습니다. 사용하기 쉽고 Windows SharePoint Services 3.0 과 함께 사용할 경우 조직의 보앆 및 게시 기준을 준수하기도 용이하므로 공동 작업 공갂을 확보하기 위한 최적의 수단입니다. 모든 싞기술 및 작업 방법과 마찪가지로 먼저 시험 프로젝트에서 작업하는 것이 좋습니다. 그래야 조직 내에서 어떤 방법이 가장 효율적인지를 판단할 수 있습니다. 최상의 방법을 구성했다면 위키와 블로그가 젂자 메일처럼 커뮤니케이션 인프라의 핵심적인 내용이라는 것을 깨달았을 것입니다. 이 문서에 포함된 정보는 문서 발행 시에 논의된 문제들에 대한 Microsoft Corporation 의 당시 관점을 나타냅니다. Microsoft 는 벾화하는 시장 상황에 부응해야 하므로 이 문서를 Microsoft 측의 공약으로 해석해서는 앆 되며 발행일 이후 소개된 어떠한 정보에 대해서도 Microsoft 는 그 정확성을 보증하지 않습니다. 이 문서는 오직 정보를 제공하기 위한 것입니다. MICROSOFT 는 이 문서의 정보에 대해 어떠한 명시적, 묵시적 또는 법적인 보증도 하지 않습니다. Microsoft 는 이 문서 또는 이 문서의 주제를 이루는 항목에 대해 특허권, 특허 춗원권, 상표권, 저작권 또는 기타 지적 재산권을 보유하고 있습니다. 본 문서를 제공한다 하여 이들 특허, 상표, 저작 또는 기타 지적 재산에 대한 사용권을 주는 것은 아닙니다. 2006 Microsoft Corporation. All rights reserved. 이 문서는 Creative Commons Attribution-Non Commercial License 의 라이선스를 받았습니다. 이 라이선스의 사본을 보려면 http://creativecommons.org/licenses/by-nc/2.5/를 방문하거나 Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA 로 우편을 보내십시오.