SharePoint의 비즈니스 이점 살펴보기

귀사의 직원 중 SharePoint에서 최고의 가치를 얻고 있는지 생각해 본 사람이 있습니까? 표면적으로 이것은 어리석은 질문처럼 보입니다. 회사에서 아직 진정한 이점과 전반적인 가치를 결정하지 않은 경우 SharePoint를 구현해야 하는 이유는 무엇입니까?

그러나 다른 기술 및 비즈니스 담당자와 일상적인 대화를 나누다 보면 그들이 SharePoint에서 보는 실제 ROI를 식별하고 정량화할 수 없는 경우가 얼마나 많은지 알고 놀랐습니다. 훨씬 더 놀라운 것은 얼마나 많은 회사가 전체 비즈니스 비용을 줄이고 생산성을 높이기 위해 SharePoint 환경을 완전히 활용하지 않는다는 것입니다.

SharePoint의 기술적인 세부 사항도 중요하지만 이 문서에서는 SharePoint를 사용하는 회사의 비즈니스 전략에서 일반적으로 누락된 사항에 대해 더 자세히 알려드리고자 합니다.

SharePoint를 사용하는 이유: 비전…

2009년 겨울의 어느 일요일, 나는 창가 자리에 앉아 747을 간절히 바라봤다. 나는 내 첫 번째 컨퍼런스인 VSLive에 참석하기 위해 샌프란시스코로 향하고 있었다.

당시 나는 대기업 화장품 회사에서 일하고 있었다. 등록한 SharePoint 수업에 참석하게 되어 매우 기뻤습니다. 회사 내의 비교적 새로운 기술 스택이었고 SharePoint가 회사를 위해 실제로 무엇을 할 수 있는지 직접 확인하고 싶었습니다.

나는 실망하지 않았다. 나는 그런 설렘을 안고 샌프란시스코를 떠났고, 내 직업 경력에서 오래전에 사라졌다고 생각했던 느낌이 들었습니다. 이 놀라운 도구에 대해 팀과 논의하기 위해 사무실로 돌아가고 싶었지만... 글로벌 정보 시스템 팀의 디렉터로 존재하는 현실을 다시금 생각하게 되었습니다.

[전무이사 – GIS] : “네, 셰어포인트에 대해 들어본 적이 있습니다. 나는 모든 소란이 무엇인지 알지 못합니다… 우리는 우리 자신의 웹 팜 내에서 동일한 웹 페이지를 만들 수 있습니다. 시간을 낭비하고 있는 것 같아요.”

[비즈니스 관계 관리자 – GIS] : “너무 평범하고 보기 흉합니다. 나는 이것을 내 비즈니스 고객에게 절대로 팔 수 없을 것입니다.”

[선임 개발자 – GIS] : “큰일이 뭐죠? 나는 그것이 어떤 가치를 더하는 것을 보지 못한다. 작업하기에는 너무 복잡해 보입니다. Active Server Pages가 훨씬 더 나은 방향이라고 생각합니다.”

조금이라도 관심을 보인 사람은 제가 직접 보고한 감독님뿐이었습니다. 그는 SharePoint 내의 기술에 대해 많이 몰랐지만, 단순히 무시하기에는 내가 너무 흥분하고 있다는 것을 알고 있었습니다.

그는 이 기술에 대해 조금 더 논의하기 위해 짧은 회의를 주선해 달라고 요청했습니다. 그 회의를 통해 우리는 고위 경영진을 위한 SharePoint 개념 증명(POC)을 엔지니어링하게 되었으며, 이는 결국 GIS 부서의 핵심 구성 요소가 되었습니다. 그것은 우리의 새로운 소프트웨어 개발 수명 주기(SDLC) 프로세스를 자동화 및 능률화하고 많은 SharePoint 이점을 수용하는 회사로 가는 길을 인도하여 저를 "The SharePoint Guy"의 눈에 띄는 수준으로 끌어올릴 것입니다. 다음 8년 동안 저는 SharePoint를 놀라운 저비용 생산성 도구로 활용하는 회사에서 많은 시간을 보낼 것입니다. 들어줄 사람이라면 많은 비즈니스 프로세스를 개선하고 비용을 절감하겠지만, 회사 내에는 여전히 문서 라이브러리가 있는 단순한 팀 사이트인 사이트가 너무 많습니다. 나는 단지 한 사람에 불과했고, SharePoint를 내 비즈니스뿐만 아니라 조직 내에서 가장 고위층에 판매하기 위해 상류로 헤엄쳤습니다.

이 소리가 익숙합니까?

지난 9년 동안 저는 대부분의 회사에서 SharePoint를 사용하는 경우 두 가지 기본 시나리오 중 하나를 사용하는 것을 관찰했습니다.

1. 문서 라이브러리가 있는 팀 사이트

이러한 사이트는 일반적으로 팀 템플릿에서 생성되며 매우 복잡한 폴더 구조를 가질 수 있는 하나 이상의 문서 라이브러리를 포함합니다. 콘텐츠 유형, 메타데이터 태그 또는 워크플로를 거의 사용하지 않습니다. 사이트는 구성원이 SharePoint에 대해 정식으로 이해하지 못하고 "고급 사용자" 역할을 수용하지 않은 사업부에서 완전히 지원됩니다. 사이트는 간단한 헬프 데스크 요청 티켓에서 사이트를 신속하게 생성할 수 있는 인프라 또는 지원 팀에 의해 생성되었습니다.

2. 크고 복잡한 코드 기반으로 완전히 사용자 정의된 사이트

일반적으로 이들은 훨씬 더 많은 청중을 가진 훨씬 더 큰 사이트입니다. 회사 인트라넷, 회사 HR 및 회사 IT 사이트는 이러한 유형의 SharePoint 사용에 대한 일반적인 후보입니다.

이러한 프로젝트는 일반적으로 큰 방향과 기대를 가지고 시작합니다. 기업에서 이미 조사한 고가의 고급 CMS(콘텐츠 관리 시스템)에 대한 저렴한 대안으로 판매되고 있습니다. 그런 다음 프로젝트가 진행됨에 따라 요구 사항이 변경되고 더 복잡해집니다. 더 많은 사용자 지정 코드가 필요하며 결국 코드 지원이 문제가 될 정도로 복잡해집니다.

여기에서 일이 일반적으로 통제 불능 상태로 나선다. 개발 팀은 제한된 코드 기반으로 즉시 사용 가능한(OOTB) 기능을 유지한다는 전제를 포기했습니다. 대신 완전히 사용자 정의된 마스터 페이지에서 PHA(제공자 호스팅 앱) 또는 현재 제공자 호스팅 추가 기능에 이르기까지 완전히 사용자 정의된 접근 방식을 사용합니다.

벌써 한숨 소리가 들리고 눈이 돌아가는 것이 보입니다. "토니, 이것은 완벽하게 유효한 활용 접근 방식입니다." "우리는 이 두 가지를 모두 가지고 있으며 사용자는 사이트를 좋아하며 지원하는 데 문제가 없습니다." 저는 이러한 방법 중 하나가 틀리거나 하나가 다른 방법보다 유리하다고 주장하는 것은 아닙니다. 하지만 두 가지 방법 모두 SharePoint 플랫폼이 제공하는 것을 완전히 활용할 수 있는 기회를 놓치고 있다고 생각합니다.

더 나아가 이 두 모델로 인해 비즈니스에서는 SharePoint가 사용 목적에 비해 너무 비싸다고 생각하거나 IT 부서에서 웹 서버와 HTML 페이지 또는 미리 준비된 CMS를 통해 동일한 기능을 단순히 개발할 수 있었다고 생각한다고 믿습니다. 클라우드 솔루션. 어느 쪽 의견이든 비즈니스와 IT 모두에서 SharePoint가 그들의 요구에 적합한 도구가 아닌 것처럼 느끼게 됩니다.

SharePoint의 이점이 완전히 사라졌습니까?

우리가 어디에 있는지 더 잘 이해하려면 뒤로 물러나서 어떻게 여기까지 왔는지 검토해야 합니다.

"SharePoint에 대해 어떻게 알게 되었습니까?"라는 간단한 질문으로 돌아가겠습니다. 제 개인적인 경험과 저와 이야기를 나눈 많은 다른 IT 리더의 경험에 따르면 기술 플랫폼으로서의 SharePoint는 Microsoft Enterprise 고문의 도움으로 인프라 팀에서 회사에 도입되었습니다.

일반적으로 첫 번째 SharePoint 팜은 Microsoft와의 기업 계약의 일부로 회사에 제공되는 일종의 테스트 베드입니다. 이 시점에서 대부분의 회사는 비즈니스 클라이언트를 참여시키고 단일 팀 사이트와 함께 첫 번째 사이트 모음을 배포합니다. 비즈니스 클라이언트는 문서 라이브러리와 문서 공동 작업 및 공유 기능을 좋아하므로 비즈니스 프로세스의 일부로 사이트를 사용하기 시작합니다.

이것은 많은 사람들에게 완벽하게 받아들여질 수 있으며 솔직히 SharePoint의 실행 가능한 사용 사례가 될 수 있습니다. 그러나 SharePoint에 대해 좀 더 깊이 파고들면 인프라 팀이 구현하고 지원하는 플랫폼이 아니라 인프라, 엔터프라이즈 아키텍처 및 응용 프로그램 팀의 긴밀한 협력이 필요한 강력한 응용 프로그램 공간이라는 것을 알게 됩니다.

저는 "반인프라" 사람이나 인프라 팀에 정치적으로 반대하는 사람이 아니지만 처음부터 올바른 파트너의 협력 없이는 SharePoint 플랫폼의 전체 범위를 이해하지 못할 위험이 있으며 따라서 적절한 비즈니스 전략 및 활용 계획에 대한 준비가 되어 있지 않습니다. 이 상황은 SharePoint 플랫폼에만 국한되지 않으며 많은 IT 부서가 직면하고 있는 적절한 공동 작업 및 전략의 훨씬 더 큰 문제를 나타냅니다.

귀하의 비즈니스 고객이 핵심입니다

많은 기술 조직에서 SharePoint와 관련된 비즈니스 전략이 전혀 없는 경우가 너무 많습니다. 그들은 단순히 SharePoint 사이트를 요청하고 만드는 방법에 대한 기존 프로세스에 작은 프로세스를 추가했습니다. 여기에는 사이트 생성 프로세스와 관련된 어떤 종류의 거버넌스도 포함되지 않을 수 있으며, 이로 인해 매우 많은 양의 사이트 모음이 발생하고 결국에는 지원 문제가 발생할 수 있습니다.

SharePoint에서 사이트 모음 및 검색 과 같은 일부 더 큰 개념의 사용에 대한 몇 가지 기본적인 대화 및 교육이 있을 수 있습니다. 그러나 전략에 대한 논의는 매우 복잡해질 수 있습니다. 이 때문에 많은 기술 조직은 단순히 사이트 생성 프로세스에서 전략을 끝내기로 결정합니다. 대신 기본 주요 SharePoint 기능을 사용하여 천천히 시작해 보겠습니다.

귀하의 비즈니스 고객은 누구입니까? 그들은 기업 기술 팀입니까, 지역 마케팅 팀입니까, 아니면 R&D 팀입니까? 앞서 언급했듯이 SharePoint 구현은 일반적으로 인프라 팀에서 시작한 다음 천천히 비즈니스 클라이언트로 전달됩니다.

어떤 경우에는 비즈니스 클라이언트가 SharePoint의 두 번째 사용이 일반적으로 시작되는 대규모 주요 기간 업무 응용 프로그램을 고려할 때 더 간단한 컨텍스트에서 SharePoint에 대해 이미 들었을 것입니다. 명확한 비즈니스 채택 전략이 없으면 기술 팀이 SharePoint 팜에 적절한 양의 채택 및 사용을 보장하기 위한 매우 느리고 힘든 여정이 될 것입니다.

필자의 경우 SharePoint를 처음 접했을 때 이미 만들어진 대부분의 SharePoint 사이트는 폴더 구조가 매우 복잡하고 복잡한 대규모 문서 라이브러리가 있는 공동 작업 사이트였습니다.

일부 폴더 이름은 실제로 팀이 폴더에 어떤 유형의 문서가 있는지 정확히 이해할 수 있도록 작은 문장이었습니다. 메타데이터 태그도, 콘텐츠 유형도 없었고 단지 폴더에 있는 문서만 있었습니다.

협업의 전 과정은 실제 문서를 공유하는 것이었습니다. 모든 사람이 문서를 공유할 수 있는 단일 저장소가 있었고 그것이 팀의 협업 범위였습니다. 이것이 비즈니스 클라이언트가 SharePoint의 가장 큰 가치로 본 것입니다.

내가 비즈니스 사람들과 이야기를 시작했을 때 SharePoint에 대한 그들의 인상이 기껏해야 열광적이지 않았던 것은 놀라운 일이 아닙니다. 내 기술 담당자 중 일부는 파일과 폴더 구조를 처리하기 위해 파일 공유를 구입하기만 하면 상당한 비용을 절약할 수 있다고 주장하기 시작했습니다.

기본 SharePoint 기능 중 많은 부분이 내 비즈니스와 기술 팀에 어느 정도 제대로 전달되지 않았습니다. 그들은 공동 작업과 혁신을 강화할 수 있는 훌륭한 가능성을 지닌 놀라운 CMS 도구로 SharePoint에서 판매되었지만 우리가 생각해낼 수 있는 최선은 파일 공유였습니다.

내 비즈니스에서 첫 번째 인터뷰 중 일부 긴 폴더 구조의 이유는 사람들이 특정 파일을 찾을 수 있도록 일정 수준의 구조를 제공하기 위함이라는 것을 알게 되었습니다. 비즈니스는 SharePoint 모범 사례를 따르는 것은 고사하고 SharePoint의 기본 검색 기능조차 인식하지 못했습니다 . 저는 비즈니스 고객이 SharePoint를 보다 효율적으로 활용할 수 있을 뿐만 아니라 플랫폼의 진정한 장점에 대해 교육할 수 있도록 참여시킬 방법을 찾아야 했습니다.

더 나은 비즈니스 사례 제시

위의 비즈니스 고객과의 인터뷰에서 피드백을 바탕으로 교육부터 시작해야 한다는 것을 깨달았습니다. 그러나 우리가 현재 가지고 있는 이미 큰 농장을 기반으로 하여 이미 진행 중인 상황에서 어떻게 "다시 시작"할 수 있었습니까?

대부분의 사이트는 문서 라이브러리가 있는 팀 공동 작업 사이트였습니다. 그래서 문서 라이브러리로 시작하기로 결정했습니다. 내 비즈니스 고객 중 한 명이 나와 내 팀과 함께 폴더 구조를 최소화하는 동시에 사용자가 찾고 있는 올바른 파일을 찾는 가시성을 높일 수 있는 방식으로 라이브러리를 재구성하는 데 동의했습니다.

일부 사이트의 구조를 더 깊이 파고들면서 폴더 구조는 실제로 팀이 공동 작업 중인 다양한 유형의 파일을 그룹화한 데이터 요소라는 것이 분명해졌습니다. 그래서 SharePoint의 매우 기본적이지만 강력한 기능인 메타데이터 태그부터 시작하기로 결정했습니다.

저는 항상 고객에게 기술에 대해 교육하는 가장 강력한 방법 중 하나는 일종의 POC를 개발하는 것이라고 생각했습니다. POC의 문제는 비용에 영향을 미친다는 것입니다. 기업이 원하는 것이 아니라고 결정하도록 애플리케이션을 완전히 개발하지 않도록 주의해야 합니다.

제 경우에는 비용이 최소화되었지만 그 가치는 잠재적으로 엄청났습니다. 각각 20개 이상의 개별 폴더가 있는 여러 문서 라이브러리를 가져와 메타데이터 및 콘텐츠 유형이 있는 하나의 문서 라이브러리로 다시 만들기로 결정했습니다. 콘텐츠 유형을 설명하는 것보다 콘텐츠 유형을 사용하여 데이터 구조에 추가할 수 있을 뿐만 아니라 파일과 관련된 추가 메타데이터를 적절하게 제어할 수 있는 방법을 보여주는 것이 더 쉬웠습니다.

눈덩이 효과

많은 파일에는 중요하고 매우 유용한 정보가 포함되어 있습니다. 회사는 매우 복잡한 폴더 구조를 사용하여 파일을 그룹화하기로 결정했습니다. 예를 들어, 15개 브랜드 각각에 대한 폴더가 있고 이 폴더 안에 마케팅, 재무 및 기타 주요 범주에 대한 하위 폴더가 있습니다. 그 하위 폴더 안에는 더 많은 하위 폴더가 있습니다.

이를 통해 개별 파일을 열어 볼 필요 없이 특정 파일을 더 쉽게 찾을 수 있었습니다. 그러나 이러한 복잡한 폴더 구조 때문에 이제 모든 파일이 올바른 폴더에 배치되었는지 확인하는 비즈니스 프로세스가 필요했습니다. 그들이 알게 된 바와 같이 새로운 비즈니스 프로세스는 관리하기 너무 어려웠고 많은 파일이 잘못된 위치에 있었습니다.

이를 통해 비즈니스에 메타데이터 사용을 통합하고 설명할 수 있었습니다. 파일 구조를 몇 가지 주요 콘텐츠 유형으로 분류한 다음 중요한 데이터 유효성 검사와 함께 주요 데이터 요소를 포함하는 데 사용했습니다. 콘텐츠 유형, 메타데이터 및 데이터 유효성 검사에 대한 이 간단한 접근 방식은 SharePoint에 대한 더 나은 비즈니스 사례를 내 비즈니스에 제시하기 위한 여정에서 첫 번째 주요 성공이었습니다.

이제 비즈니스의 관심을 받았으므로 주요 이해 관계자와 함께 문서 라이브러리를 간단히 둘러보기로 했습니다. 데이터를 필터링하고 정렬하여 메타데이터 및 콘텐츠 유형의 진정한 가치를 보여주었습니다.

놀랍게도 그들은 존재조차 몰랐던 기본적인 SharePoint 기능 중 일부에 경외감을 느꼈습니다. 그런 다음 몇 가지 간단한 페이지 생성, 웹 파트 및 필터링으로 수행할 수 있는 작업을 실제로 보여주기 위해 사용자 지정 필터 페이지를 포함하기로 결정했습니다.

나는 이 페이지들 중 어떤 것도 완전히 사용자화하지 않도록 매우 조심했습니다. OOTB 웹 파트만 사용하고 싶었습니다. 그렇게 하면 내가 더 복잡한 시나리오로 넘어가기 전에 기본 SharePoint 기능을 더 잘 이해할 수 있을 것입니다. 사용자 정의 페이지는 큰 성공을 거두었고 검색 엔진이 제공할 확장된 기능에 대해서는 논의조차 하지 않았습니다. SharePoint 기본 사항을 더 잘 채택할 때까지 검색 엔진을 보류하고 싶었습니다.

SharePoint 워크플로: 핵심

제 개인적인 견해로는 SharePoint 워크플로는 비즈니스 고객을 교육하고 조직 내에서 SharePoint의 채택 및 사용을 보장하는 능력에서 가장 중요한 단일 요소였습니다. 워크플로는 내가 언급한 첫 번째 VSLive에서 내 관심을 끈 첫 번째 기능이었고, 우리 SDLC 프로세스를 통합한 첫 전체 SharePoint POC에 주요 기여자였습니다.

SharePoint와 관련하여 비즈니스 고객과의 초기 대화는 일반적으로 비즈니스 프로세스에 관한 것입니다. 비즈니스 프로세스는 SharePoint를 사용하여 생산성을 높이고 비용을 줄이는 데 핵심적인 역할을 합니다. 이는 모든 비즈니스 클라이언트가 논의하기를 열망하는 부분입니다.

많은 고위 IT 경영진에게 말했듯이 비즈니스 프로세스를 통해 SharePoint의 사용 및 채택을 실질적으로 보장할 수 있습니다. 모든 사업부에는 프로세스가 있으며 이러한 프로세스의 대부분에는 체크포인트 또는 승인 지점이 있습니다. 여기에서 승인 이메일 전송이든 승인 작업 생성이든 상관없이 워크플로가 유용합니다.

워크플로가 프로세스를 개선하고 비용을 절감할 수 있는 방법에 대해 비즈니스 고객에게 확신을 주고 나면 동일한 승인 작업을 사용하여 서비스 수준 계약(SLA) 또는 핵심 성과 지표(KPI)를 생성하는 방법에 대해 교육합니다.

문서를 검토하고 승인하는 데 걸리는 시간을 사업부에서 이해하면 얼마나 좋을까요? 그런 다음 해당 정보를 가져와 전체 프로세스를 개선하기 위한 전략을 채택할 수 있습니다. 그러면 프로세스를 모니터링하고 관리하는 KPI를 만들 수 있습니다.

프로세스 개선에 대한 고위 경영진의 약속을 보여주기 위해 보너스 목표 프로그램의 일부로 개선 사항을 포함할 수도 있습니다. 이것은 일반적으로 비즈니스 클라이언트에게 SharePoint의 채택 및 사용을 통해 얻을 수 있는 진정한 가치를 확신시키는 홈런입니다.

미래

Office 365 및 SharePoint Online에 대해 처음 들었을 때 호스팅된 SharePoint 환경의 가치를 이해했지만 다시 이 새로운 방향이 그들의 미래를 위한 최선임을 비즈니스 고객에게 확신시키는 방법에 대해 고심했습니다. PHA에 대해 듣게 되어 기뻤지만 애플리케이션 지원 관점에서 PHA가 가질 수 있는 잠재적인 비용에 대해서도 조심스러웠습니다.

우리 회사는 아웃소싱 모델을 사용하여 타사 개발 공급업체의 방향을 따라 시작했는데, 이는 공급업체가 유지 관리 및 개선에 대한 큰 잔여 비용으로 복잡한 비즈니스 응용 프로그램을 쉽게 만들 수 있게 만들 수 있습니다.

모든 호스팅 모델과 마찬가지로 변화에 대비해야 합니다. 인간으로서 우리는 변화를 정말로 좋아하지 않으며 기술 지원 팀으로서 우리는 종종 변화와 그것이 우리 팀의 전진 능력에 어떤 영향을 미칠지 두려워합니다.

Microsoft가 InfoPath를 더 이상 사용하지 않기로 결정한 후 워크플로 엔진으로 Flow를 도입했다는 소식을 처음 들었을 때 내 반응은 "다시 시작하겠습니다!"였습니다. Microsoft는 내가 최신 SharePoint 방향을 "판매"하는 것을 더 어렵게 만드는 또 다른 비즈니스 결정을 내리려고 했습니다. Flow가 제공해야 하는 것을 검토하기 시작하면서 나는 내가 본 것에 실망했습니다.

그러나 Microsoft는 그들의 미래 비전을 가지고 있었고, 통합 지점과 관련하여 Flow의 일부 기능을 보기 시작할 때까지 저는 단순히 이해하지 못했습니다. Flow는 오늘날의 많은 기존 애플리케이션과 통합되지만 회사가 자체 통합 지점을 만들 수도 있습니다. 이로 인해 다양한 LOB(기간 업무) 응용 프로그램과의 통합을 통해 개선된 비즈니스 프로세스에 대한 내 비즈니스 토론의 주요 참여자가 되었습니다.

유동성

이것은 기술 임원인 제가 많은 비즈니스 고객과 나누는 대화의 표준 주제가 되었습니다. 반응형 웹 디자인과 모바일 웹 존재를 향상시키기 위해 이를 최대화하는 방법에 대해 논의하는 것은 괜찮습니다. 또한 SharePoint가 반응형 웹 페이지를 활용하여 모바일 장치에서 더 나은 SharePoint 환경을 만드는 방법에 대해서도 논의할 수 있습니다. Microsoft는 모바일 SharePoint 애플리케이션도 개발했습니다. 그러나 일반적으로 논의는 독립형 모바일 애플리케이션을 갖는 방향으로 진행됩니다.

"독립형 모바일 응용 프로그램"이라는 단어를 듣자마자 금전 등록기 의 소리가 들립니다. 많은 모바일 응용 프로그램은 전문 지원 모델과 함께 높은 비용 공간을 차지합니다. SharePoint 세계에서 내 대답은 PowerApps입니다.

과거에 했던 것처럼 모바일 PowerApps POC 애플리케이션 개발을 즉시 시작합니다. 기존 SharePoint 목록 및 라이브러리를 내 응용 프로그램의 백 엔드 데이터 원본으로 활용합니다. PowerApps는 내가 구성 기반 개발 플랫폼 이라고 부르는 것입니다. 모바일 애플리케이션을 매우 빠르게 개발할 수 있습니다.

사용자는 SharePoint에서 PowerApps 옵션을 선택하여 자신의 PowerApps 모바일 응용 프로그램을 만들 수 있습니다. 목록이나 라이브러리에 새 항목을 추가하고 편집하는 많은 화면을 자동으로 생성합니다. 또한 모바일 장치 분야의 모든 현재 리더와 함께 테스트되었습니다. 기술 개발자 또는 기술에 정통한 고급 사용자가 쉽게 적용할 수 있는 매우 간단한 구성 기반 언어와 함께 자체 IDE가 있습니다.

다시 한 번 저는 SharePoint 플랫폼의 채택 및 사용을 개선하는 데 사용할 수 있는 훌륭한 SharePoint 도구/기능을 갖게 되었습니다. 이 새로운 도구를 SharePoint 및 Flow와 함께 푸시 알림 및 위치 서비스 및 전화 통화와 같은 본질적으로 모바일 기능을 사용할 수 있는 기능을 통합하면 PowerApps가 공유 지점.

사실 내 POC는 내 비즈니스에서 열성적으로 받았을 뿐만 아니라 위치 서비스 및 GPS 탐색과 같은 모바일 기능을 사용하기 때문에 PowerApps 엔지니어링에 내 POC 애플리케이션을 제시하라는 요청을 받았습니다. 도구.

VSLive에서 SharePoint 솔루션으로

샌프란시스코로 향하는 창가 자리에 앉았을 때 나는 그 간단한 여행이 내 기술 경력에 어떻게 그렇게 큰 영향을 미칠지 상상할 수 없었습니다. SharePoint는 진정으로 혁신적이고 협업적인 도구이며 Microsoft는 SharePoint를 통해 계속해서 비전과 방향을 제시하고 있습니다.

오늘날 우리가 사용할 수 있는 수천 개의 SaaS 또는 PaaS 솔루션과 마찬가지로 우리는 이러한 솔루션을 가장 잘 활용하는 방법을 진정으로 이해하고 있는지 확인해야 합니다. 전반적인 비즈니스 프로세스를 지속적으로 개선하고 비즈니스 고객을 만족시키기 위해 SharePoint는 제 무기고의 핵심 도구가 되었습니다. 나는 미래와 SharePoint가 나와 내 비즈니스에 무엇을 제공할 것인지 기대합니다.