Dataverse for Teams and what it means for users and admins?

Starting from mid November 2020 users of Office 365 and Microsoft Teams have been able to create Dataverse for Teams environments within standard O365/M365 licensing. What this actually means for end users and IT admins? What they have to consider when using this new feature?

Summary

As a summary Microsoft Power Platform is a platform to visualize data, build apps, automate workflows, build chatbots and store data by centralized way to Dataverse as a low-code approach. But wait… I thought Common Data Service was part of Power Platform? Haven’t heard about Dataverse? Microsoft renamed Common Data Service as Dataverse and the same time Dataverse for Teams came generally available (11/2020). Also some other main terminology changes came effective related to Dataverse environments: Entities -> Tables, Records -> Rows, Fields -> Columns.

Screenshot showing overview of Microsoft Power Platform.

Previously utilizing Dataverse (CDS) required advanced licensing model for Power Platform. Also using some advanced features like Power Virtual Agents and AI Builder required Dataverse as a background service so they were also binded to advanced licensing model. Since the launch Dataverse for Teams end users are now able to create “light-weight” Dataverse instances within their Microsoft Teams context. This allows a completely new approaches and options for individual teams and employees to start working with their data. Also building Power Virtual Agents is now possible through Dataverse for Teams… and it’s easy!

Creating Dataverse for Teams environment for your team

To create a Dataverse for Teams instance to your Team you have to add “Power Apps” or “Power Virtual Agents” (or both) Teams app to your Teams client. Simply access “Apps” button on lower left corner of Teams UI, search for Power Apps and then choose the app and select “Add”. You can be owner or member of the team and Team itself can be private, public or organization wide.

This will add app to your Teams left navigation. Remember to pin it with right click! Now you can access the new interface which allows of creating a new Power App (and Dataverse for Teams environment on background) for selected Team. I prefer using “Power Apps” Teams app as a main interface since it contains more features than “Power Virtual Agents” app and it launches the later one when needed.

You will end up to this kind of polished Canvas Power App editor which allows you to edit your canvas app and/or to create a new Table to newly created Dataverse for Teams environment. Ignoring building Table or Canvas App itself here actually doesn’t matter, you now have Dataverse for Teams environment on background. Of course you can start building app right away.

Later accessing “Build” tab of Power Apps app you can list all Teams which have Dataverse for Teams environment created and you have access as owner or member. From “New” button here you are also able to start creating a Chatbots (Power Virtual Agents).

By selecting “See all” option from previous view you can easily see all the artifacts from selected Team. This view also actually allows the full management of Tables and their columns as well as table data if needed. Notice all column types for tables are not available from other views! You can of course create multiple custom tables if needed, add custom columns and create relationships between tables.

End User considerations

  • You can build Canvas Power Apps, Power Automates or Power Virtual Agents
  • All standard and premium connectors are available. However you should prefer standard connectors to really get benefit from licensing changes.
  • Applications based for Dataverse for Teams only works in Microsoft Teams context. You can’t run these as standalone or add them to your company Intranet portal or so.
  • Remember this approach can be a data silo in a negative manner!
  • Considering previous bullets, make sure to scope you application correctly. Who are the actual users needs access to data? Is this really for your team only or should we actually build organization level application? How much data you are going to store considering limits we have? Your company must have some kind of Playbook for utilizing Dataverse for Teams.
  • Data is accessible by owners and members of the team. Guest users can use apps but by default they only see their own items from Tables for example. Individual access to PowerPlatform environment can be given through Power Apps admin center.
  • Many advanced feature from actual Dataverse is not available. REST API is missing, Dataverse access right model is missing, no Business Rules, no Webhooks and no plugins for example. You can’t create Model Driven Apps at all based for Table.
  • You can update Dataverse for Teams to actual Dataverse environment if needed – Option however is not yet available!
  • There is a limit of 2GB and/or 1 million rows of data per team (and per Dataverse for teams instance)

IT Admins consideration

  • By default all end users can add required apps to their teams and create Dataverse for Teams environments. This behavior can be blocked or changed through Teams Admin Center App policies.
  • 500 Dataverse for Teams environments can be created per Office 365 tenant. This is a current hard limit and can’t be changed.
  • Dataverse for Teams environments doesn’t count or effect for actual PowerPlatform and Dataverse capacity in your tenant.
  • All Dataverse for Teams are actual PowerPlatform environments and can be seen through Power Apps Admin center as “Microsoft Teams” typed environments.
  • You can setup and configure PowerPlatform DLP policies against these environments if needed.
  • By default Dataverse for Teams environment is deleted when the connected Team is deleted. However Dataverse for Teams PowerPlatform environments can be deleted on background without deleting actual Teams for example to get more quota for new active environments.
  • You should take this new PowerPlatform environment type under consideration in your Governance models.

Final words

Even the whole concept of Dataverse for Teams may sound a bit complicated I feel this a really good track and addition to current toolbox of Microsoft Teams. By informing and training end users, having a Playbook for them and getting these environments under ICT governance models there are again a lot more possibilities for organization and individual teams to be more efficient. And I love Power Virtual Agents already!

Microsoft Power Platformin käyttöönoton ensiaskeleet

Microsoftin Power Platform on yhä vahvempi tekijä, kun puhutaan nk. “low-code” alustoista. Ne mahdollistavat monia sovelluskehityksen ja sovellusautomaation mahdollisuuksia graafisen käyttöliittymän kautta ilman työlästä sovelluskehitystä. Tämä malli leikkaa tyypillisesti sovelluksen käyttöönottoon tarvittavaa aikaa sekä erityisesti kustannuksia. Alustan avulla loppukäyttäjät voivat tehdä monia asioita, jotka aiemmin eivät olleet mahdollisia ainakaan ilman raskaita ja kalliita sovelluskehityksen ponnisteluita. Power Platformin käyttöönotto voikin parhaimmillaan tehostaa työntekijöiden ajankäyttöä merkittävästi ja tuoda tätä kautta kustannussäästöjä, yleistä tehokkuuden paranemista sekä lisätä henkilöstön yleistä tyytyväisyyttä.

Myös Gartner listasi aiemmin syksyllä Microsoftin Power Platformin low-code alustojen tämän hetkiseksi markkinajohtaksi: https://powerapps.microsoft.com/en-us/blog/gartner-names-microsoft-a-leader-in-enterprise-low-code-application-platforms-2019-magic-quadrant/

Kirjoittelin tämän vuoden MS Igniten pohjalta yhteenvetoa jo aiemmin, ja sieltä löytyy muutama sananen myös Power Platformista: https://newway2work.blog/2019/11/13/ms-ignite-2019-loppukayttaja-ottaa-modernin-tyon-yha-vahvemmin-omiin-kasiinsa/

Lähde: Microsoft Ignite 2019 – POWA10: Enabling everyone to digitize apps and processes with Power Apps and the Power Platform

Tässä blogissa esittelen yksinkertaistettuna Power Platform -ympäristön käyttöönoton perustarpeet. Oletus on, että organisaatio haluaa hyödyntää ja lähteä liikkeelle seuraavilla kokonaisuuksilla:

  • Graafiset Canvas-tyyppiset Power Appsit ja niiden päälle rakennetut kevyet sovellukset
  • Työnkulut ja sovellusautomaatio niiltä osin, kun tarpeita on tunnistettu
  • Em. kokonaisuudet halutaan tuoda kaikkien työntekijöiden saataville sekä toisaalta halutaan tehdä muutamia “virallisia” sovelluksia organisaatiolle

Mitä pitää vähintään huomioida?

1) Power Platform-ympäristöt

Kaikkiin Office 365 -tenantteihin muodostuu automaattisesti yksi default -ympäristö (Environment). Tähän ympäristöön päätyvät oletuksena kaikki luotavat Power Appsit ja Power Automate-työnkulut. Lisäksi kaikilla käyttäjillä on oikeus luoda em. komponentteja ympäristöön.

Ympäristöjä voidaan hallita Power Platformin Admin Centerin kautta osoitteessa https://admin.powerplatform.microsoft.com/environments.

Organisaation tarpeista riippuen pitäisi luoda ainakin toinen ympäristö tuotantokäyttöön (Type “Production”), johon kasataan organisaation viralliset sovellukset. Tähän ympäristöön voidaan antaa rajatummat käyttöoikeudet ympäristökohtaisen nk. maker-roolin puitteissa, jolloin kokonaisuus on paremmin hallittava. Tähän liittyy myös ympäristön kesken jaettujen datayhteyksien tietoturva ja tarvittaessa myös ympärisökohtaiset DLP-policyt. Lisäksi voidaan perustaa esim. kehitysympäristö, johon voidaan myös määrittää erikseen oikeuksia tyypillisesti default- ja tuotantoympäristön välimaastosta.

Esimerkki Power Platform-ympäristöistä tenantissa

2) Erillinen automaatiotunnus

Power Platformin käyttöön kannattaa luoda erillinen automaatiotunnus, joka omistaa lähtökohtaisesti tuotanto-ympäristön sovellukset. Ei ole väliä, onko tämä tunnus lokaali AD:n tunnus vai “Cloud Only”-tyyppinen Azure AD-tunnus. Tämän omistajatunnuksen rinnalle voidaan tuoda co-owner roolissa esim. IT:n henkilöiden tunnukset / ryhmät. Tätä kautta säilytetään hyvä näkyvyys kaikkiin ympäristössä oleviin sovelluksiin sekä mahdollistetaan tarvittavat huoltotoimet.

Hyviä syitä automaatiotunnuksen luomiseen ovat ainakin:

  • Perinteinen sovelluksen omistajan lähtö yrityksestä -> Orvot työnkulut ja Power Appsit
  • Tarvittaessa kaikilla hallintorooleilla pääsy sovelluksiin yhden tunnuksen kautta
  • Sovelluksen sisäiset datayhteydet määritellään usein samalle tunnukselle, joka omistaa sovelluksen -> Huomioi tunnuksen näkyvyys loppukäyttäjille tietyin yhdistimin, kuten esim. sähköpostin lähetys tai Teams-viestin lähetys
  • Yhdistimien vaatimat oikeudet taustalla voivat olla järeitä Office 365 admin-rooleja -> selkeä luvitusmalli
  • Tarvittaessa MFA-autentikaatio voidaan pitää voimassa myös tässä mallissa

3) Lisensointitarpeet

Lisensointitarpeet on hyvä selvittää heti alkuun. Perusyhdistimet ja esim. SharePoint-listan hyödyntäminen tietovarastona kuuluvat peruslisensointiin ja itse asiassa näillä päästään peruskäyttötapauksissa ja perussovelluksissa hyvinkin pitkälle.

Esimerkki saatavilla olevista perusyhdistimistä

Erikseen maksullisia Per App ja Per User -lisensointimalleja tarvitaan ainakin seuraavissa tapauksessa mikäli:

  • Hyödynnetään premium-yhdistimiä
    • Dynamics 365-yhdistimet
    • Azure-yhdistimet ml. Azure SQL / Cosmos DB
    • GraphAPI ja sitä vasten tehtävät operaatiot
  • Käytetään Common Data Serviceä (CDS) tietovarastona
  • Käytetään ominaisuuksia, jotka tarvitsevat toimiakseen CDS:ää esim. AI Builder, Portal-tyyppiset Power Appsit, Power Virtual Agents jatkossa
  • Käytetään OnPremise Data Gateway:tä tapauksissa, joissa datalähde sijaitsee lokaalissa konesalissa

Lisensointi tulee aina miettiä tapauskohtaisesti ja esim. se, onko organisaatiolla käytössä Dynamics 365, vaikuttaa Power Platformin käyttömahdollisuuksiin merkittävästi. Uusin ohjeistus lisensointiin löytyy täältä https://docs.microsoft.com/en-us/power-platform/admin/powerapps-flow-licensing-faq.

4) Virallisten Canvas-tyyppisten Power Appsien ulkoasu ja käytettävyys

Liian usein tulee vastaan graafisia Power Appseja, joiden ulkoasu on jotakin “sinne päin”. Jotta loppukäyttäjien olisi mukava käyttää sovelluksia, edes perus saavutettavuusvaatimukset täyttyisivät ja applikaatiosta kävisi selkeästi ilmi minkä organisaation sovellus on kyseessä esim. vieraskäyttötapauksissa, olisi organisaation sähköisten kanavien ulkoasuun muutenkin sovellettavat ohjeet syytä huomioida myös Power Appsien puolella mahdollisuuksien mukaan. Esimerkkejä:

  • Perusilme aina samanlainen – Ylä- ja alatunnisteen sisältö
  • Perusnavigoitavuus ja esim. “koti”-painikkeen lokaatio
  • Käyttöliittymän suunnittelu jonkinlaisen “parhaan käytännön” mukaisesti niin, että liittymän perusasiat ovat kunnossa
  • Organisaation värimaailma ja logo applikaatiossa
  • Saavutettavuuden perusasiat: Riittävän suuri ja selkeä fontti, selkeät ja erottuvat elementit, riittävät kontrastit elementeissä jne.
Valmiita saatavilla olevia Canvas Power Apps-templaattimalleja

5) Sovelluksen loppukäyttäjät

Miksi sovellus olikaan olemassa? Todennäköisesti helpottaakseen loppukäyttäjien elämää ja päivittäisen työn tekemistä. Näin ollen loppukäyttäjät tulee huomioida monella eri rintamalla:

  • Ks. kohta 4. yhtenä tärkeimmistä
  • Loppukäyttäjien ja koko henkilöstön mahdollisuus ja tuki alustan ominaisuuksien hyödyntämiseen. Alustan perusominaisuudet käytössä kaikilla työntekijöillä Office 365 Business / E1 / E3 / E5-lisensointitasoilla ja myös F1 -lisensointi mahdollistaa sovellusten käytön
  • Tarvittava koulutus, jotta peruseväät ja “uskallus” hyödyntää ominaisuuksia ovat olemassa
  • Power Platform tulee ottaa osaksi käyttöönoton- ja muutoksen tukea organisaatiossa. Jos olette määritelleet esim. Office 365 -käytön Pelikirjaa, tulisi Power Platformin elementtien olla myös mukana Pelikirjassa
  • Yrityksen käytössä oleva mobiililaitteisto ja laitekanta

6) Kevyt hallintomallitarve virallisille sovelluksille

Vaikka Power Platform tuo kevyen mallin sovellusten rakenteluun ja hyödyntämiseen, ei sekään toimi ilman perushallintomallin määrittelyä. Organisaatiossa IT:n tai alustastavastaavien tahojen pitää pysyä perillä tilanteesta myös Power Platformin suhteen ja tarvittaessa esim. tarjota tukea, jos loppukäyttäjillä tulee ongelmia virallisten sovellusten kanssa. Samoin jos esim. sovelluskumppanin halutaan tekevän kehitystä alustalle, pitää kokonaisuuteen olla määriteltynä selkeä malli.

Hallintomallin tulisi sisältää vähintään seuraavat määrittelyt:

  • Kehitys- ja tuotantoonvienti prosessi virallisille applikaatioille – Missä ympäristössä kehittäminen tapahtuu? Kuka vie sovellukset tuotantoon? Missä ympäristössä bugikorjaukset tehdään? Miten jatkokehitys hoidetaan?
  • Sovellusten versiointi ja varmistus – Liittyy suuresti edelliseen kohtaan, mikä myös määrittelee sovellusten ja työnkulkujen versiointia. Vaikka sovellukset säilyvätkin ympäristöissä ja kuuluvat esim. Microsoftin perusvarmistusten piiriin, halutaanko uusista versioista viedä exportatut sovelluspaketit (ja tarvittaessa esim. SharePointin listatemplaatit) vielä erikseen organisaation versionhallintaan?
  • Yhtenevät nimeäsmiskäytännöt – Vaikka rakennettu sovellus muodostuisi esim. Canvas Power Appsista, Power Automate työnkulusta ja SharePointin listasta, ei suoraa linkitystä näiden elementtien välillä välttämättä ole sovellusnäkökulmasta. Dokumentaatio sovelluksista on hyvä olla olemassa ja eri komponentit tulee myös nimetä niin, että myöhemmin on helppo kertoa mitkä niistä liittyvät a) toisiinsa b) mihinkin toiminnalliseen kokonaisuuteen.
  • Power Appsien uudelleenjulkaisu ja yhdistimen versiopäivitykset tietyllä syklillä – Jotta Microsoftin päivitykset ja esim. yhdistimien suorituskykyyn liittyvät parannukset tulevat voimaan, tulisi Power App-sovellukset aika-ajoin julkaista uudelleen. Lisäksi Power Automaten yhdistimissä tapahtuu parannuksia ja versiopäivityksiä (kuten esim. juuri nyt Outlook-yhdistimen version päivittyminen V3 -> V4) ja nämä versiopäivitykset eivät automaattisesti päivity työnkulkuihin.
  • Ympäristöjen ja applikaatioiden monitorointi – Admin Centerin hallintaliittymien kautta on saatavilla jatkossa dataa siitä miten esim. Power Appseja käytetään organisaatiossa. Käyttöä tulisi mitata ja dataa pystyä hyödyntämään samalla tavoin kuin muutakin Office 365:n tuottamaa vastaavaa analytiikkaa toimintapojen kehittämisessä.
  • Virhetilanteiden selvitys ja tukitoiminnot – Power Platformin sovellukset ovat sovelluksia siinä missä kaikki muutkin sovellukset. Vastaavalla tavalla niissä ilmenee välillä loppukäyttäjillä ongelmia, joihin tarvittaessa pitää pystyä vastaamaan. Yrityksellä tulisi olla selkeä tukimalli esim. oman IT:n ja tarvittaessa vaikkapa sovelluskumppanin kautta.

Hyödyllisiä linkkejä ja dokumentteja, joilla päästä alkuun Power Platformin parissa

Lopuksi vielä muutamia linkkejä ja dokumentteja, jotka helpottavat Power Platformin käynnistelyä. Kun perusasiat ovat kunnossa, on vakaalla pohjalla mukavaa lähteä rakentamaan sovelluksia ja tätä kautta parantamaan työntekijöiden arkea ja päivittäistä työskentelyä.

MS Ignite 2019 – Loppukäyttäjä ottaa modernin työn yhä vahvemmin omiin käsiinsä

Intensiivinen Ignite-viikko Orlandossa on nyt takana. Aikaerosta ja matkustamisesta on myös sen verran selvitty, että on aika vetää yhteen viikon antia sekä miettiä, mihin olemme matkalla.

Tapahtuman keynotessa tuottavuustyökalujen osalta Microsoft käytti nimitystä “The world’s productivity cloud”. Tätähän Microsoft 365-pilviympäristö todellakin nykyään on – maailmanlaajuinen, tietoturvallinen, monipuolinen, käyttäjäkeskeinen sekä samalla yhä helppokäyttöisempi kivijalka, jonka varaan on hyvä rakentaa niin pienen kuin suurenkin yrityksen toimintaa. Ne lukijat joille Office 365 on terminä tutumpi – Microsoft 365 on siis käytännössä Office 365:n laajennettu lisensointimalli, joka tuo perustasollaan mukanaan myös Windows 10:n sekä tietoturvan ja päätelaitehallinnan ominaisuuksia.

Microsoft 365 
The world's productivity cloud

Moderni SharePoint & Intranet

Moderni SharePoint on ottanut viimeisen vuoden aikana suuria askelia eteenpäin, ja tiekartta sekä tehdyt julkistukset tulevista ominaisuuksista olivat johdonmukaista jatkoa sille.

Kokonaan uutena palveluna on tulossa Project Cortex, joka tuo tekoälyyn perustuvan tiedon automaattisen linkityksen ja analysoinnin sekä tämän pohjalta aihesivujen, tietokeskuksen ja aihekorttien automaattisen muodostamisen saataville.

Lisäksi tulossa on navigaatioiden kohdentaminen, parannuksia kokoomasivustojen ominaisuuksiin ja hallittavuuteen, suuri määrä parannuksia SharePoint-listojen ominaisuuksiin, listojen paremman integroitumisen Teamsin käyttöliittymään ja niin edelleen. Lista on pitkä.

Moderni SharePoint on responsiivinen, tyylikäs, helppokäyttöinen, vakio-ominaisuuksiltaan jo nyt hyvin monipuolinen sekä moderneja käyttötapauksia tukeva. Mukauttaminen on helppoa SharePoint Frameworkin (SPFx) avulla tilanteissa, joissa mukautukset ovat selkeästi perusteltuja. Samoja mukautuksia webosissa voidaan hyödyntää myös suoraan Microsoft Teamsin käyttöliittymän kautta.

Ilo oli myös nähdä, miten yritykset ovat huomanneet ja valjastaneet modernin SharePointin kyvykkyydet ja mm. kattavat modernit uutisointiominaisuudet. Samoin on huomattu, että loppukäyttäjät voivat itsekin tehdä paljon ilman ulkopuolista apua, mikä tuo nopeutta ja joustavuutta tekemiseen.

Klassisen ajattelumaailman kysymyksiä oli sessioissa yhä harvemmassa. Modernin SharePoint-ympäristön valmisominaisuuksien riittävät mahdollisuudet on vihdoinkin alettu ymmärtää myös muualla kuin esim. Suomessa (jossa kuljemme tässä asiassa aika eturintamassa). SharePointin (tai Intran) mukautuksiin tai “valmis-intraan” ei kannata enää yksinkertaisesti käyttää aikaa, rahaa tai vaivaa suuria summia. Ennemminkin halutaan pysytellä valmisominaisuuksissa ja hyödyntää niitä järkevällä tavalla.

Maailma on myös muuttunut siinä, miten Intranet organisaatioissa rakentuu. Yhä enemmän kaikki käyttäjät ovat mukana sisällöntuotannossa ja ulkoasuun tehdään vain kevyt brändäys. Alustat kuten Yammer ja Microsoft Teams mahdollistavat läpinäkyvän informaation kulun ja sisällön tuottamisen, johon kaikki loppukäyttäjät osallistuvat. Toisaalta loppukäyttäjät voivat myös valita esim. roolinsa perusteella luontevimman tavan ja sähköisen kanavan kuluttaa tätä sisältöä.

Intranet konseptina siis mukautuu nykyajan tarpeisiin ja ennen Intralle luontaisia funktioita toteuttavat yhä enemmän kaikki Office 365:n työkalut yhdessä. Moderni “Intranet”-käyttöönotto onkin nykyään kevyemmän teknisen lähestymisen ohella enemmän käyttäjälähtöinen kokemus. Projektissa mietitään organisaation viestintää kokonaisuutena ja sitä miten uudet työtavat ja Microsoft 365:n tarjoamat mahdollisuudet saadaan hyödynnettyä tehokkaasti juuri kyseisessä organisaatiossa niin viestinnän kuin ryhmätyönkin osalta.

Microsoft Teams & Yammer

Myös Microsoft Teamsin ja Yammerin osalta Ignite tarjosi paljon.

Yammerin uusi ulkoasu julkaistiin ja Office 365-ryhmiin tehdään pesäeroa muuttamalla Yammer-ryhmien nimi yhteisöiksi (communities). Lisäksi saamme uuden Teams-appsin, jolla Yammer on helppo tuoda osaksi Teamsin käyttöliittymää, mikä selkeyttää ja helpottaa Yammerin käyttöä oleellisesti. Microsoftin aiemmin lanseeraama Inner loop (Teams) – Outer loop (Yammer)-ajattelu tukee taas paremmin kokonaisuutta. Päivittäinen työskentely siis tapahtuu Teamsin kautta, mutta Yammerin kautta loppukäyttäjät voivat jakaa omaa tietoutta ja tekemistä muulle organisaatiolle yli siilojen suoraan Teamsistä.

Teamsin osalta kauan odotetut privaattikanavat tulevat vihdoin tuotantoon nopealla aikataululla jo tällä viikolla. Samoin käyttöä helpottavat erilliset keskusteluikkunat ovat tulossa alkuvuodesta. Lisäksi esiteltiin malli jaella Power Appseihin perustuvia applikaatioita helposti Teamsin sovelluskeskuksen kautta organisaatiossa yhdessä uuden applikaatiokatalogin kanssa. Jatkossa voidaan siis tuoda yrityksen ja eri henkilöstöroolien toimintaa tukevat Power Apps-sovellukset suoraan Teamsin vasemman reunan navigaatioon, jolloin niiden käyttäminen helpottuu. Lisäksi mainittakoon Teamsin uudet tehtävät ja keskitetty näkymä kaikkien eri tehtävätyyppien hallintaan Office 365:ssa. Tämä on ehdottamasti odotettu uudistus.

Microsoft Teams alkaa myös olla “de facto” ryhmätyön alusta yrityksissä, joissa Office 365 on käytössä. Ajatuksena työn käyttöliittymä on toimiva ja antaa tiimeille, eri funktioille ja yksilöille valtavasti mahdollisuuksia organisoitua tehokkaasti oman toimintansa ympärille käyttäjälähtöisesti kunhan tämä tehdään hallitusti ja siten, että kaikki käyttäjät tuntevat organisaation pelikirjan ja yhteiset pelisäännöt. Jatkossa Teamsin rooli entisestään vahvistuu ja yhä useampaa liiketoimintasovellusta tiedon tai sovelluksen sijainnista riippumatta tullaan käyttämään luontaisesti Teamsin kautta. Tämä tarkoittaa myös mukautusten ja lisätoimintojen tuomista Teamsin kontekstiin. Tämän myötä organisaation Teams-osaaminen, Teams-kyvykkydet sekä avoin organisaatiokulttuuri ja yhteiset pelisäännöt nousevat yhä voimakkaammin tekemisen ja osaamisen keskiöön.

Ignitessa oli myös vahvasti esillä Teams-yhteensopivia laitteita ja Microsoft Teams Rooms- sekä Focus Rooms-konseptit. Lisäksi lanseerattiin uusi Managed Meeting rooms-palvelu. Kokonaisuuden täydentää Surface Hub 2 ja näppärät integroidut whiteboard-toiminnallisuudet. Kokoukseen liittyminen ja kokouksen aloittaminen näillä on todella vaivatonta ja kokouskokemus ylipäätään sujuva. Olemme tulleet kauas ongelmallisista Skype-kokouksista ja hyvä niin!

Microsoft Power Platform

Igniten ehkä parasta antia oli mielestäni Microsoft Power Platformiin liittyvät sessiot ja alustan avaamat mahdollisuudet. Power Platform tulee ja kovaa! Monet organisaatiot tekevät alustan käyttöönottoa parhaillaan sekä automatisoivat prosessejaan. Proof of Concept-hengessä toteutuksia yhä useampien liiketoiminta- tai tuottavuussovelluksien tuomiseksi Power Platformin päälle on menossa leveällä rintamalla. Ignitessa moni suurempi yritys myös esitteli omia, jo tuotannossa olevia Power Platform-sovelluksiaan ja jakoi kokemuksia niistä.

Power Platform on alusta, joka koostuu seuraavista komponenteista:

  • Eri tyyppiset Power Appsit – Sovellukset ja UI
  • Power Automate – Työnkulut, automaatio, yhdistimet (aiemmin MS Flow)
  • Power BI – Tiedon visualisointi ja analysointi
  • Power Virtual Agents – Vuorovaikutteiset toiminnot perustuen botteihin

Power Platform sisältää valmiita yhdistimiä moniin eri järjestelmiin ja ideana on low-code/no-code- tyyppinen lähestyminen, jossa sovelluksia ja automaatiota voidaan rakentaa käyttöliittymän kautta helposti ilman syvää koodausosaamista. Kun loppukäyttäjät itse ryhtyvät tekemään tätä, puhutaan kansalaiskoodauksesta. Power Platformin hyödyntäminen leikkaa ideaalitapauksessa suuresti sovelluskehityksen kustannuksia ja tarvittavaa kalenteriaikaa sovelluksen rakentamiseksi.

Monet yhdistimet ja ominaisuudet vaativat erikseen lisensointia mutta monet tarpeet hoituvat myös olemassa olevin Office 365 F1/E3-lisenssein kuten visuaalisen canvas-tyyppisen Power Appsin ja Power Automaten avulla hyödyntäen tuttua SharePointin listaa tietovarastona. Toisena esimerkkinä erilaisten syötteiden saaminen ja niihin reagoiminen suoraan Teamsin käyttöliittymästä vaikkapa mukautuvien korttien avulla ja kaikki yhden käyttöliittymän takaa.

Myös Power Platformin tulevaisuus näyttää erittäin vahvalta. Yhä parempi integroituminen Teamsiin, AI Builder-ominaisuus, jossa tekoälyä voidaan opettaa ja hyödyntää suoraan Power Appsien kautta vaikkapa kuvien sisällön tunnistamiseen, Ignitessa julkaistut RPA-ominaisuudet joilla voidaan automatisoida myös toimintoja ruudulla nauhoitettujen käyttäjäinteraktioiden pohjalta ja PCF (PowerApps Component Framework) Power Appsien komponenttien laajentamiseksi avaavat lähes rajattomasti uusia  hyödyntämismahdollisuuksia.

Kaikki tämä on lähtökohtaisesti myös loppukäyttäjien suoraan hyödynnettävissä.

Muutoksen tuki organisaatiossa (Adoption)

Se, miten muutosta ja käyttäjiä organisaatiossa tuetaan, on noussut jo aiemmin keskeiseksi elementiksi Microsoft 365 -käyttöönotoissa. Jo tätä blogia lukiessa ymmärtää, miksi muutoksen tukeminen ja siirtyminen jatkuvan kehityksen malliin korostuu entisestään

  • Microsoft 365 käyttöönotto on aina kokonaisuus ja organisaatiolle usein kokonaan uusi tapa toimia. Muutos lähtee aina yksilöstä ja siitä että yksilö kokee muutoksen tarpeellisena ja hyödyllisenä itselleen
  • Loppukäyttäjillä on yhä suurempi mahdollisuus osallistua sisältöjen tuottamiseen,  keskusteluun ja heillä on parempi näkyvyys siihen mitä organisaatiossa tapahtuu kokonaisuutena
  • Loppukäyttäjillä ja tiimeillä on yhä suurempi mahdollisuus vaikuttaa itse siihen, mitä työkaluja ja millä tavoin he haluavat niitä omassa työssään hyödyntää
  • Aiemmasta poiketen toimintojen mukauttaminen käyttötapausten mukaiseksi loppukäyttäjien toimesta on mahdollista ja jopa toivottavaa
  • Käyttäjille syntyy tarve ymmärtää paremmin Microsoft 365-kokonaisuutta ja potentiaalia
  • Muutoksen pysyvyys ja nopeakin tarve omaksua uusia ominaisuuksia on uusi normi
  • Kun digitaalinen ympäristö mahdollistaa kaiken edellä kuvatun, on yhteistyön toimivuuden kannalta koko ajan tärkeämpää, jopa elintärkeää, johtaa muutosta niin, että työyhteisö toimii samojen peruskäytäntöjen mukaisesti. Yhteistyö ei vain toimi, jos kaikki säntäilevät joka suuntaan omien mielihalujen ja oivallusten vieminä.

Muutoksen tukeminen (end user adoption) onkin syystä myös Microsoftilla yksi tämän vuoden avain-focuksista. Loppukäyttäjän ja tiimien käsissä on yhä enemmän mahdollisuuksia käyttää tuottavuustyökaluja haluamallaan tavalla. Lisäksi on tärkeää ymmärtää että em. työkalujen käyttöönotto, prosessien ja pelikirjan määrittely sekä tekemisen kehittäminen eivät suinkaan ole kertaluontoisia ponnistuksia. Uusia ominaisuuksia tulee koko ajan, jopa viikoittain, ja samalla organisaation on myös mietittävä miten saada hyödyt irti maksetuista lisensseistä sekä miten organisoitua jatkuvan muutoksen mallin ympärille. Myös hallintamallit ja avustavat työkalut sekä prosessit vaativat päivitystä.

Oleellista tässä kaikessa on myös se, että alustan ylläpidon, mukautettujen sovelluksien ylläpidon ja esim työläiden jatkokehitysponnisteluiden sijaan panokset voidaan nyt käyttää ketterästi aitojen hyötyjen, liiketoimintaa aidosti edistävien, loppukäyttäjiä tukevien sekä yrityksen toimintaa tehostavien ratkaisujen eteenpäin viemiseksi.