SharePoint'in İş Avantajlarını Keşfetmek

İşletmenizdeki herhangi biri, SharePoint'ten en fazla değeri alıp almadığını hiç düşündü mü? Yüzeyde, bu gülünç bir soru gibi görünüyor. Bir şirket, gerçek faydalarını ve toplam değerini henüz belirlemediyse neden SharePoint'i uygulasın?

Ancak diğer teknik ve iş insanlarıyla yaptığım günlük görüşmelerde, SharePoint'te gördükleri gerçek yatırım getirisini ne sıklıkla belirleyip ölçemediklerini görünce hayret ediyorum. Daha da şaşırtıcı olan şey, kaç şirketin toplam iş maliyetini azaltmak ve üretkenliği artırmak için SharePoint ortamlarını tam olarak kullanmamış olmasıdır.

SharePoint'in teknik özellikleri önemlidir, ancak bu makalede, SharePoint kullanan şirketlerin iş stratejisinde tipik olarak eksik olan şeyler hakkında sizinle daha fazla paylaşmak istiyorum.

Neden SharePoint Kullanılır: Bir Vizyon…

2009 kışında bir Pazar günü, penceredeki koltuğuma oturdum ve hevesle 747'den dışarı baktım. İlk konferansım VSLive'a katılmak için San Francisco'ya gidiyordum.

O zamanlar büyük bir kozmetik firmasında çalışıyordum. Kaydolduğum SharePoint derslerine katılmaktan heyecan duydum: Şirket içinde nispeten yeni bir teknoloji yığınıydı ve SharePoint'in şirket için gerçekten neler yapabileceğini kendim görmek istedim.

hayal kırıklığına uğramadım. San Francisco'dan öyle bir heyecanla ayrıldım ki, profesyonel kariyerimden çoktan çıktığını düşündüğüm bir duygu. Ekibimle bu harika aracı tartışmak üzere ofise geri dönmeye o kadar hevesliydim ki...

[İcra Direktörü – GIS] : “Tabii ki, SharePoint'i duydum. Bütün bu yaygaranın ne hakkında olduğunu anlamıyorum… Aynı web sayfalarını kendi web çiftliğimizde yapabiliriz. Bence zamanını boşa harcıyorsun."

[Business Relationship Manager – GIS] : “Bu çok basit ve çirkin. Bunu hiçbir zaman ticari müşterilerimden birine satamayacağım.”

[Kıdemli Geliştirici – GIS] : “Önemli olan ne? Herhangi bir değer kattığını görmüyorum. Çalışmak için çok karmaşık görünüyor. Bence Active Server Pages çok daha iyi bir yön.”

Biraz da olsa ilgi gösteren tek kişi, doğrudan rapor verdiğim yönetmendi. SharePoint'teki teknolojiler hakkında pek bir şey bilmiyordu ama benim bunu görmezden gelemeyecek kadar heyecanlı olduğumu biliyordu.

Bu teknolojiyi biraz daha tartışmak için kısa bir toplantı ayarlamamı istedi. Bu toplantı, üst yönetimimiz için sonunda GIS departmanı içinde temel bir bileşen haline gelecek olan bir SharePoint kavram kanıtı (POC) tasarlamamıza yol açtı. Yeni yazılım geliştirme yaşam döngüsü (SDLC) süreçlerimizi otomatikleştirecek ve düzene sokacak ve şirketin birçok SharePoint avantajını benimsemesine yol açarak beni önde gelen “SharePoint Guy” seviyesine ulaştıracaktı. Önümüzdeki sekiz yıl boyunca zamanımın çoğunu şirkette SharePoint'i inanılmaz bir düşük maliyetli üretkenlik aracı olarak kullanarak geçirecektim. Dinlemek isteyenler için, birçok iş sürecini iyileştirip maliyetlerini düşürürdüm, ancak şirket içinde hala belge kitaplıklarına sahip basit ekip siteleri olan çok fazla site vardı. SharePoint'i yalnızca kendi işime değil, aynı zamanda kuruluştaki en üst düzeylere satmak için akıntıya karşı yüzen bir kişiydim.

Bu Kulağa Tanıdık Geliyor mu?

Son dokuz yılda, çoğu şirkette SharePoint kullanımının iki temel senaryodan birinde gerçekleştiğini gözlemledim.

1. Belge Kitaplıklarına Sahip Ekip Siteleri

Bu siteler genellikle Ekip şablonundan oluşturulur ve çok karmaşık klasör yapılarına sahip olabilen bir veya daha fazla belge kitaplığı içerir. İçerik türleri, meta veri etiketleri veya iş akışları çok az kullanılır. Siteler, üyeleri resmi bir SharePoint anlayışına sahip olmayan ve “Güçlü Kullanıcı” rolünü benimsemeyen iş birimi tarafından tam olarak desteklenmektedir. Site, basit bir yardım masası istek biletinden hızlı bir şekilde site oluşturabilen altyapı veya destek ekibi tarafından oluşturulmuştur.

2. Büyük, Karmaşık Kod Tabanlı Tamamen Özelleştirilmiş Siteler

Genellikle, bunlar çok daha büyük bir kitleye sahip çok daha büyük sitelerdir: Kurumsal intranetler, kurumsal İK ve kurumsal BT siteleri, bu tür SharePoint kullanımı için olağan adaylardır.

Bu projeler genellikle büyük yön ve beklentilerle başlar. İşletmenin halihazırda araştırdığı birçok yüksek kaliteli, pahalı içerik yönetim sistemine (CMS) düşük maliyetli bir alternatif olarak satılmaktadır. Ardından proje ilerledikçe, gereksinimler değişir ve daha karmaşık hale gelir. Daha fazla özel koda ihtiyaç duyar, bu da sonunda kodu desteklemenin bir sorun haline gelmesine yetecek kadar karmaşık hale gelir.

Buradan işler genellikle kontrolden çıkar. Geliştirme ekibi, sınırlı bir kod tabanıyla kullanıma hazır (OOTB) işlevsellik ile kalma fikrinden vazgeçti. Bunun yerine, tamamen özelleştirilmiş Ana Sayfalardan, muhtemelen sağlayıcı tarafından barındırılan bir uygulamaya (PHA) veya şimdiki adıyla sağlayıcı tarafından barındırılan bir eklentiye kadar tamamen özelleştirilmiş bir yaklaşıma sahiptirler.

İç çekişleri şimdiden duyabiliyor ve göz devirmelerini görebiliyorum. "Tony, bunlar tamamen geçerli kullanım yaklaşımları." "Bunların her ikisine de sahibiz ve kullanıcılarımız siteleri seviyor ve onları desteklemekte hiçbir sorunumuz yok." Hiçbir şekilde bu yöntemlerden birinin yanlış olduğunu veya birinin diğerine göre avantajlı olduğunu iddia etmiyorum, ancak her iki yaklaşımın da SharePoint platformunun sunduğu şeylerden tam olarak yararlanma fırsatını kaçırdığına inanıyorum.

Ayrıca, bu iki modelin iş dünyasında SharePoint'in kullandıkları şey için çok pahalı olduğu hissine yol açtığına veya BT departmanının web sunucuları ve HTML sayfaları veya hazır bir CMS aracılığıyla aynı işlevi basitçe geliştirebileceklerini düşünmesine neden olduğuna inanıyorum. bulut çözümü. Her iki görüş de hem işletmeyi hem de BT'yi SharePoint'in ihtiyaçları için doğru araç olarak görmemesi gibi hissettiriyor.

SharePoint Kaçırıldı mı?

Nerede olduğumuzu daha iyi anlayabilmemiz için bir adım geri atıp buraya nasıl geldiğimizi gözden geçirmemiz gerekiyor.

Sizi "SharePoint'i nasıl duydunuz?" sorusuna geri götüreceğim. Kişisel deneyimim ve konuştuğum diğer birçok BT liderinin deneyimlerinden yola çıkarak, Microsoft Enterprise danışmanlarının yardımıyla altyapı ekibinden şirkete teknik bir platform olarak SharePoint tanıtıldı.

Genellikle, ilk SharePoint grubu, şirkete Microsoft ile Kurumsal Anlaşmalarının bir parçası olarak verilen bir tür test yatağıdır. Bu noktada, çoğu şirket bir iş müşterisiyle bağlantı kurar ve ilk site koleksiyonlarını tek bir ekip sitesiyle dağıtır. İş istemcisi, belge kitaplıklarını ve işbirliği yapma ve belgeleri paylaşma yeteneğini sever ve bu nedenle siteyi iş süreçlerinin bir parçası olarak kullanmaya başlar.

Bu, birçoğunuz için tamamen kabul edilebilir gelebilir ve dürüst olmak gerekirse, SharePoint için uygun bir kullanım örneği olabilir. Ancak SharePoint'i biraz daha derinlemesine incelediğinizde, bunun altyapı ekibinin uyguladığı ve desteklediği bir platformdan çok daha fazlası olduğunu anlarsınız: Bu, altyapının, kurumsal mimarinin ve uygulama ekiplerinin sıkı işbirliğini gerektiren sağlam bir uygulama alanıdır.

Ben “altyapı karşıtı” bir kişi veya altyapı ekibine siyasi olarak karşı olan biri değilim, ancak en başından doğru ortakların işbirliği olmadan, SharePoint platformunun tüm kapsamını anlamama riskini taşırsınız ve bu nedenle uygun iş stratejilerine ve kullanım planına hazırlıksız yakalanırlar. Bu durum, SharePoint platformuna özgü değildir ve birçok BT departmanının karşı karşıya olduğu çok daha büyük bir uygun işbirliği ve strateji sorununa işaret eder.

İş Müşteriniz Anahtardır

Çoğu zaman, birçok teknik kuruluşun, söz konusu SharePoint olduğunda kesinlikle hiçbir iş stratejisi yoktur. Bir SharePoint sitesinin nasıl isteneceği ve oluşturulacağı konusunda mevcut süreçlerine eklenmiş küçük bir süreçleri vardır. Site oluşturma süreci etrafında herhangi bir yönetim biçimini içermeyebilirler, bu da çok büyük miktarda site koleksiyonuna ve nihayetinde bir destek sorununa yol açabilir.

Site koleksiyonları ve SharePoint'te Arama gibi bazı daha büyük kavramların kullanımıyla ilgili bazı temel konuşmalar ve eğitimler olabilir. Ancak strateji tartışmaları çok karmaşık hale gelebilir. Bu nedenle, birçok teknik kuruluş stratejilerini site oluşturma sürecinde sonlandırmaya karar verir. Bunun yerine, yavaş ve temel SharePoint özellikleriyle başlayalım.

Ticari müşterileriniz kimler? Kurumsal teknik ekip mi, bölgesel pazarlama ekibiniz mi, yoksa Ar-Ge ekibi mi? Daha önce de belirttiğim gibi, SharePoint uygulaması genellikle altyapı ekibi tarafından başlatılır ve ardından yavaş yavaş iş istemcisi popülasyonuna damlar.

Bazı durumlarda, iş müşterileriniz, SharePoint'in ikinci kullanımının genellikle başladığı büyük ölçekli, önemli bir iş kolu uygulamasını düşünürken, SharePoint'i daha basit bir bağlamda zaten duymuş olacaklardır. Net bir iş benimseme stratejisi olmadan, teknik ekip için SharePoint çiftliklerinin doğru miktarda benimseme ve kullanıma sahip olmasını sağlamak çok yavaş ve zorlu bir yolculuk olacaktır.

Benim durumumda, SharePoint ile tanıştığımda zaten oluşturulmuş olan SharePoint sitelerinin çoğu, çok karmaşık ve dolambaçlı klasör yapılarına sahip büyük belge kitaplıklarına sahip işbirliği siteleriydi.

Klasör adlarından bazıları aslında küçük cümlelerdi, böylece ekip klasörde tam olarak ne tür belgeler olduğunu anlayabildi. Hiçbir meta veri etiketi, içerik türü yoktu, yalnızca klasörlerde oturan belgeler vardı.

Tüm işbirliği süreci, gerçek belgelerin paylaşılmasıydı. Herkesin belgeleri paylaşabileceği tek bir havuz vardı ve bu, ekip için işbirliğinin kapsamıydı. İş müşterisinin SharePoint'in en büyük değeri olarak gördüğü şey buydu.

İş yerindeki insanlarla konuşmaya başladığımda, SharePoint hakkındaki izlenimlerinin en iyi ihtimalle hevesli olmamasına şaşmamalı. Teknik meslektaşlarımdan bazıları bile, dosyaları ve klasör yapılarını yönetmek için sadece dosya paylaşımları satın alırsak büyük bir maliyet tasarrufu yapabileceğimizi tartışmaya başladılar.

Temel SharePoint özelliklerinin çoğu, işime ve bir dereceye kadar teknik ekibe bile düzgün bir şekilde iletilmedi. SharePoint'te, işbirliğini ve yeniliği güçlendirmek için harika olanaklara sahip harika bir CMS aracı olarak satıldılar, ancak bulabileceğimiz en iyi şey dosya paylaşımıydı.

İşimdeki ilk röportajlarımdan birinde, bazı uzun klasör yapılarının nedeninin, insanların belirli dosyaları bulması için bir düzeyde yapı sağlamak olduğunu öğrendim. İş, SharePoint'in en iyi uygulamalarını takip etmek şöyle dursun , SharePoint'in temel arama özelliklerinin bile farkında değildi . SharePoint'i yalnızca daha verimli bir şekilde kullanabilmeleri için değil, aynı zamanda onları platformun bazı gerçek güçlü yönleri hakkında eğitmek için iş müşterilerimin ilgisini çekmenin bir yolunu bulmam gerekiyordu.

Daha İyi Bir İş Vakasının Sunulması

Ticari müşterilerle yaptığım yukarıdaki görüşmelerden aldığım geri bildirimlere dayanarak, her şeye eğitimle başlamam gerektiğini anladım. Ancak halihazırda sahip olduğumuz büyük çiftliğe dayanarak, işler zaten ilerlerken nasıl “yeniden başlayabilirdim”?

Sitelerin çoğu, belge kitaplıklarına sahip ekip işbirliği siteleriydi. Bu yüzden belge kitaplıkları ile başlamaya karar verdim. İş müşterilerimden birinin, kullanıcının aradığı doğru dosyayı bulma görünürlüğünü artırırken, klasör yapılarını en aza indirecek şekilde kitaplıklarını yeniden yapılandırma konusunda benimle ve ekibimle birlikte çalışmayı kabul etmesini sağladım.

Bazı sitelerin yapısını daha derine indikçe, klasör yapılarının aslında veri öğeleri ve ekibin üzerinde işbirliği yaptığı çeşitli dosya türlerinin gruplandırmaları olduğunu anladım. Bu yüzden, SharePoint'in çok temel ama güçlü bir özelliğiyle başlamaya karar verdim: Meta veri etiketleri.

Her zaman, herhangi bir müşteriyi bir teknoloji konusunda eğitmenin en güçlü yollarından birinin, basitçe bir çeşit POC geliştirmek olduğunu hissettim. POC'lerle ilgili sorun, maliyet etkisine sahip olmalarıdır. Bir uygulamayı tamamen geliştirmemek için dikkatli olmalısınız, yalnızca işletmenin istediği şeyin bu olmadığına karar vermesini sağlamalısınız.

Benim durumumda, maliyet minimumdu, ancak değer potansiyel olarak çok büyüktü. Her biri 20 veya daha fazla ayrı klasöre sahip birden fazla belge kitaplığı almaya ve onu meta veri ve içerik türleriyle tek bir belge kitaplığı olarak yeniden oluşturmaya karar verdim. İçerik türlerini açıklamaya çalışmak yerine, bir içerik türü kullanmanın nasıl yalnızca veri yapısına ekleme yapmakla kalmayıp aynı zamanda bir dosyayla ilişkili ek meta verileri düzgün şekilde yönetmelerine izin verdiğini göstermek daha kolaydı.

Kartopu Etkisi

Dosyaların çoğu önemli, son derece yararlı bilgiler içeriyordu. İşletme, dosyaları çok karmaşık bir klasör yapısı kullanarak gruplandırmaya karar verdi. Örneğin, 15 markasının her biri için bir klasörleri vardı ve bu klasörlerin içinde pazarlama, finans ve diğer önemli kategoriler için alt klasörleri vardı; bu alt klasörler içinde daha fazla alt klasörleri vardı.

Bu, tek tek dosyaları açıp görüntülemek yerine belirli bir dosyayı veya dosyaları daha kolay bulmalarını sağladı. Ancak bu karmaşık klasör yapısı nedeniyle, her dosyanın doğru klasöre yerleştirildiğinden emin olmak için artık bir iş sürecine ihtiyaçları vardı. Öğrendikleri gibi, yeni iş sürecini yönetmek çok zordu ve birçok dosya yanlış yere gitti.

Bu, meta veri kullanımını işletmeye dahil etmemi ve açıklamamı sağladı. Dosya yapısını, daha sonra önemli veri doğrulama ile birlikte temel veri öğelerini dahil etmek için kullandığımız birkaç temel içerik türüne ayırdım. İşime SharePoint için daha iyi bir iş vakası sunma yolculuğumda ilk büyük başarı, içerik türleri, meta veriler ve veri doğrulamaya yönelik bu basit yaklaşımdı.

Artık işin dikkatini çektiğime göre, önemli paydaşlarla birlikte belge kitaplığında basit bir adım adım ilerlemeye karar verdim. Verilerini filtreleyip sıralayarak onlara meta verilerin ve içerik türlerinin gerçek değerini gösterdim.

Şaşırtıcı bir şekilde, varlığından bile haberdar olmadıkları bazı temel SharePoint özelliklerinden etkilendiler. Daha sonra, bazı basit sayfa oluşturma, web bölümleri ve filtreleme ile neler yapılabileceğini onlara gerçekten göstermek için özel bir filtre sayfası eklemeye karar verdim.

Bu sayfaların hiçbirini tamamen kişiselleştirmemeye çok dikkat ettim. Yalnızca OOTB web bölümlerini kullanmak istedim. Bu şekilde, daha karmaşık senaryolara geçmeden önce temel SharePoint özelliklerini daha iyi anlamış olacaklardı. Özel sayfa büyük bir başarıydı ve arama motorunun onlara sağlayacağı genişletilmiş yeteneklerden bahsetmemiştik bile. SharePoint temellerini daha iyi benimseyene kadar arama motorunu ertelemek istedim.

SharePoint İş Akışları: Anahtar

Mütevazı görüşüme göre, SharePoint iş akışları, kurumsal müşterilerimi eğitme ve SharePoint'in kuruluşumda benimsenmesini ve kullanılmasını sağlama yeteneğimde tek ve en önemli faktör olmuştur. Bahsettiğim ilk VSLive'da dikkatimi çeken ilk özellik iş akışlarıydı ve SDLC süreçlerimizi içeren ilk tam SharePoint POC'me büyük katkı sağladılar.

SharePoint söz konusu olduğunda, kurumsal müşterilerimle yaptığım ilk konuşmalar genellikle onların iş süreçleriyle ilgilidir. İş süreçleri, üretkenliği artırmak ve maliyetleri azaltmak için SharePoint'i kullanmanın anahtarıdır ve bu, herhangi bir iş müşterisinin tartışmaya istekli olduğu bir şeydir.

Birçok üst düzey BT yöneticisine söylediğim gibi, yalnızca iş süreçleri aracılığıyla SharePoint'in kullanımını ve benimsenmesini pratik olarak garanti edebilirim. Her iş biriminin süreçleri vardır ve bu süreçlerin çoğunun kontrol noktaları veya onay noktaları vardır ve bu, ister bir onay e-postasının gönderilmesi isterse bir onay görevinin oluşturulması yoluyla olsun, iş akışlarının kullanışlı olduğu yerdir.

Bir iş müşterisini iş akışlarının süreçlerini nasıl iyileştirebileceğine ve maliyetlerini nasıl azaltabileceğine ikna ettikten sonra, onları aynı onay görevlerini hizmet düzeyi anlaşmaları (SLA'lar) veya temel performans göstergeleri (KPI'lar) oluşturmak için nasıl kullanabilecekleri konusunda eğitiyorum.

Bir iş biriminin, bir belgenin gözden geçirilip onaylanmasının ne kadar sürdüğünü anlaması ne kadar harika olurdu? Daha sonra bu bilgiyi alabilir ve genel süreci iyileştirmek için bir strateji benimseyebilirler. Bu, daha sonra süreci izlemek ve yönetmek için KPI'lar oluşturmalarına olanak tanır.

Üst yönetimin süreçlerinin iyileştirilmesine olan bağlılığını göstermek için, iyileştirmeleri bonus hedef programlarının bir parçası olarak bile dahil edebilirler. Bu, genellikle bir iş müşterisini SharePoint'in benimsenmesi ve kullanılması yoluyla elde edebilecekleri gerçek değere ikna eden ana çalışmadır.

Gelecek

Office 365 ve SharePoint Online'ı ilk duyduğumda, barındırılan bir SharePoint ortamının değerini anladım, ancak yine de iş müşterilerimi bu yeni yönün gelecekleri için en iyisi olduğuna nasıl ikna edeceğim konusunda zorlandım. PHA'ları duyduğuma heyecanlandım, ancak bunun uygulama desteği açısından sahip olabileceği potansiyel maliyet konusunda da temkinliydim.

Şirketim, tedarikçilerin bakım ve geliştirmeler için büyük bir artık maliyetle karmaşık iş uygulamaları yaratmasına kolayca yol açabilecek bir dış kaynak kullanımı modeliyle üçüncü taraf geliştirme satıcılarının yönünü değiştirmeye başlamıştı.

Her barındırılan modelde olduğu gibi, kendimizi değişime hazırlamamız gerekiyor. İnsanlar olarak değişimi gerçekten sevmiyoruz ve teknik destek ekipleri olarak genellikle değişimden ve bunun ekibimizin ilerleme yeteneğini nasıl etkileyeceğinden korkuyoruz.

Microsoft'un InfoPath'i kullanımdan kaldırma kararını ve ardından Flow'un bir iş akışı motoru olarak kullanıma sunulduğunu ilk duyduğumda, tepkim “İşte yine başlıyoruz!” oldu. Microsoft, en yeni SharePoint yönünü "satmayı" benim için daha zor hale getirecek başka bir iş kararı alacaktı. Flow'un sunduğu şeyleri gözden geçirmeye başladığımda, gördüklerim beni hayal kırıklığına uğrattı.

Ancak Microsoft'un gelecek vizyonu vardı ve ben bunu anlayamadım - ta ki Flow'un entegrasyon noktalarıyla ilgili bazı yeteneklerini görmeye başlayana kadar. Flow, günümüzün mevcut uygulamalarının çoğuyla entegre olur, ancak aynı zamanda bir şirketin kendi entegrasyon noktalarını oluşturmasına da olanak tanır. Bu, onu çeşitli iş kolu uygulamalarıyla entegrasyon yoluyla iyileştirilmiş iş süreçleri hakkındaki iş tartışmalarımda önemli bir oyuncu haline getirdi.

Hareketlilik

Bu, teknik bir yönetici olarak birçok ticari müşterimle yaptığım standart bir konuşma konusu haline geldi. Duyarlı web tasarımını ve mobil web varlıklarını iyileştirmek için nasıl en üst düzeye çıkarılacağını tartışmak sorun değil. SharePoint'in mobil cihazlarda daha iyi bir SharePoint deneyimi oluşturmak için duyarlı web sayfalarını nasıl kullandığını da tartışabiliriz. Microsoft, bir mobil SharePoint uygulaması bile geliştirmiştir. Ancak genellikle tartışma, bağımsız bir mobil uygulamaya sahip olma yönünde ilerler.

“Bağımsız mobil uygulama” kelimesini duyar duymaz bir yazar kasanın tıkırtısını duyarım: Birçok mobil uygulama, özel bir destek modeliyle birlikte yüksek maliyetli ayak izine sahiptir. SharePoint dünyasından cevabım PowerApps.

Geçmişte yaptığım gibi, hemen bir mobil PowerApps POC uygulaması geliştirmeye başlıyorum. Uygulamam için arka uç veri kaynağı olarak mevcut SharePoint listelerini ve kitaplıklarını kullanır. PowerApps, konfigürasyon tabanlı geliştirme platformu dediğim şeydir: Mobil uygulamaların çok hızlı geliştirilmesine olanak tanır.

Bir kullanıcı, kendi PowerApps mobil uygulamasını oluşturmak için SharePoint'teki PowerApps seçeneğini belirlemesi yeterlidir. Hatta bir listeye veya kitaplığa yeni öğeler eklemek ve bunları düzenlemek için birçok ekranı otomatik olarak oluşturur. Ayrıca mobil cihaz alanındaki tüm mevcut liderlerle test edilmiştir. Kendi IDE'sine ve teknik bir geliştirici veya hatta teknoloji konusunda bilgili bir uzman kullanıcı tarafından kolayca uyarlanabilen çok basit yapılandırma tabanlı bir dile sahiptir.

Bir kez daha, SharePoint platformunun benimsenmesini ve kullanımını geliştirmek için kullanabileceğim harika bir SharePoint aracına/özelliğine sahibim. Bu yeni aracı, anında iletme bildirimleri ve konum hizmetleri ve telefon aramaları gibi doğal olarak mobil özellikleri kullanma yeteneği ile birlikte SharePoint ve Flow ile birleştirin ve PowerApps, kurumsal müşterilerimle, Paylaşım Noktası.

Aslında POC'm sadece işim tarafından hevesle karşılanmadı, aynı zamanda konum servisleri ve GPS navigasyon gibi mobil özellikleri kullanmamdan dolayı, POC uygulamamı PowerApps mühendisliğine örnek olarak neler yapılabileceğine dair sunmam istendi. alet.

VSLive'dan SharePoint Çözümlerine

San Fransisco'ya giderken pencere kenarındaki koltuğumda otururken, bu basit yolculuğun teknik kariyerim üzerinde nasıl bu kadar büyük bir etkisi olacağını asla hayal edemezdim. SharePoint gerçekten yenilikçi ve işbirliğine dayalı bir araçtır ve Microsoft, SharePoint ile vizyon ve yönelimlerini sunmaya devam ediyor.

Bugün bize sunulan binlerce SaaS veya PaaS çözümünden herhangi biri gibi, bu çözümleri en iyi şekilde nasıl kullanacağımızı gerçekten anladığımızdan emin olmalıyız. Genel iş süreçlerimizi iyileştirmeye ve ticari müşterilerimizi memnun etmeye devam eden SharePoint, cephaneliğimde önemli bir araç haline geldi. Geleceği ve SharePoint'in benim ve işim için neler sunacağını sabırsızlıkla bekliyorum.