Should we follow the general business analytical approach on Salesforce projects? Should all BA’s be BABOK certified? Is business analysis a different job when implementing SF? Should business analyst be also a solution architect and admin, or even developer? What are advantages and disadvantages of such approaches? What BA tools to use?
Do you like these questions, and have many more?
Let’s try to find answers together!
5. #CD22
What is BA in context of Salesforce projects?
… and show
case studies
… and drive
expectations
… so that it
fits SF
well…
Wish
Understand
business
needs
Find business
solutions
Prepare
architecture
Develop Test Deploy
8. #CD22
We already now know that BA must be also at least amateur architect
… but what about consultant, admin, dev, tester?
Presale & BA & delivery & …
Banking
Insurance
Health
…
BABOK
UML
…
GIT
Metadata
Administration
…
Testing
CI/CD
…
11. #CD22
● Use common sense
● Tailor BA set-up to specific context
● Do the least neccessary
● Be part of a delivery team
… see you at our Enehano Solutions stand
Summary
Říct, že kluk pro všechno
Slyšeli jste – one man project? To jsem já
Spíše sada otázek, než agenda
Zdůraznit na začátku poslouchání, neskákat do řešení, ale citlivě
Zdůraznit iniciální fáze – definice business potřeb atechnicky, rigidní přístup, poznat, popsat, analyzovat, hledat architekturu řešení…
BA jako support při testování
Od začátku musí BA posunovat klienta jen v kontextu toho, co SF umí, důraz na řízení očekávání
SF není JAVA
Hiring podtext – v Ene propojujeme bizz vertikální znalost a znalost SF, tj. naroubujeme SF tím správným způsobem
Maximálně využíváme to, co SF nabízí, musíme zákazníka poslouchat, musíme umět poradit tak, aby se potkalo přání a možnosti SF
We tend to see SF implementation like this…
But reality is more often like this…
Ano, vytrženo z kontextu, ale integrace jsou alfa-omega usazení SF do architektury zákazníka
Musíme chápat enterprise architekturu zákazníka
Naše zahleděnost do SF světa vs SF je jen 1 ze 100 systémů zákazníka
Schopnost bavit se na témata togaf capabilities
Změnit název slide, není to jen o integracích
Řízení očekávání
BA must know what SF offers vs what client can do
Incl non-fcional areas (SF limits)
Ano, vytrženo z kontextu, ale integrace jsou alfa-omega usazení SF do architektury zákazníka
Musíme chápat enterprise architekturu zákazníka
Naše zahleděnost do SF světa vs SF je jen 1 ze 100 systémů zákazníka
Schopnost bavit se na témata togaf capabilities
Jaké procesy/části procesů v SF a jaké v jiných systémech
Čím méně předávek, tím efektivnější dodávka
… univerzalita lidí
Jak je vytvářet
Říct jak v Enehano
Budujeme – jak? BA chceme mít jako konzultanta, vnímání potřeb, ale taky blízko v dev (git, metadata, flows)
Chci říct:
Musí se dělat super detailní blbuvzdorná BA doc? Předatelná na architekta, který jí dál rozloží na Dev tasky atd.?
Efektivní?
Chce to zákazník? Chtějí to ještě dnes vůbec?
Vs
BA je univerzál a napíše si zadání jen do takové míry, jak je třeba, a pak to rovnou udělá?
BA je člen agilního týmu, který sedí spolu a místo psaní se mluví?
Rigidní BA dokumentace
BRQ
BA epics/stories
Tech epics/stories
Or
BA jako role v agilním týmu
Každý BA trochu dělá
Záleží na velikosti, kontextu projektu
Detailed modeling? EA?
Just fragments of models? Lucid, Visio..?
BA through UI – Avoni creator
Podle velikosti projektů… podle očekávání zákazníka
UI důležité pro pochopení zákazníka, porototypy v Avoni