ChatGpt si při analýze rovnou vyhledala i číselníky mšmt, to je dost dobrý. Výsledný text analýzy je tento:
po porovnání těch čtyř exportů bych ten návrh upravil tak, aby CRM nebylo jen seznamem kontaktů, ale umožnilo vybírat školy k oslovení podle několika obchodně zajímavých parametrů.
Zásadní zjištění je, že všechny čtyři soubory popisují v zásadě stejná data, ale na různých úrovních podrobnosti:
Soubor Řádků dat Co představuje řádek Unikátních RED_IZO
Adresar.xlsx 1 044 právnický subjekt / ředitelství 1 044
Skoly.xlsx 2 433 konkrétní škola nebo školské zařízení 1 044
SkolyAObory.xlsx 1 520 konkrétní obor konkrétní školy 585
SkolyAMista.xlsx 3 651 konkrétní místo činnosti školy/zařízení 1 044
To je velmi důležité pro import: nedával bych do SuiteCRM čtyři importy. Základní CRM entitou bych udělal těch 1 044 právnických subjektů z Adresar.xlsx, identifikovaných pomocí RED_IZO. IČO je zde mimochodem také unikátní 1:1, ale RED_IZO bych si stejně ponechal jako primární identifikátor zdrojových dat.
Co bych do CRM dostal
Adresar.xlsx je výborný základ pro Accounts. Obsahuje jméno, sídlo, telefon, e-maily, WWW, ředitele, kraj/okres, zřizovatele atd. Pak bych k těmto 1 044 řádkům agregoval informace z ostatních tří exportů.
Pro prioritizaci bych určitě přidal minimálně tato pole:
RED_IZO
IČO
zřizovatel
kraj / okres / obec
ředitel
telefon
e-mail
web
typy škol, které organizace provozuje
kapacita
obory
případně počet míst činnosti
později vlastní CRM pole: Priorita, Stav oslovení, Poslední kontakt, Další krok atd.
Zřizovatel je přitom přesně to, co potřebujeme. Kódy v exportu jsou:
1 = MŠMT, 2 = obec, 3 = jiný ústřední orgán, 5 = soukromník, 6 = církev, 7 = kraj. To odpovídá číselníku MŠMT.
A už samotné rozložení vašich 1 044 subjektů je zajímavé:
Zřizovatel Počet subjektů
obec 460
soukromník 352
kraj 188
církev 32
MŠMT 9
jiný státní resort 3
Takže třeba možnost říct „ukaž mi obecní ZŠ nad 300 žáků“ nebo „soukromé SŠ s IT oborem“ je podle mě přesně správný cíl.
Velikost školy: máme dobrý údaj, ale s jednou výhradou
Skoly.xlsx obsahuje Kapacita. Ta je pro prioritizaci velmi použitelná, ale není to počet současných žáků.
Je to nejvyšší povolený počet dětí/žáků/studentů atd. evidovaný v rejstříku.
Takže bych pole v CRM nenazýval například Počet žáků, ale třeba:
Rejstříková kapacita
nebo
Kapacita školy
Pro obchodní segmentaci je to podle mě naprosto dostačující proxy. Škola s kapacitou 800 je zjevně jiná potenciální zakázka než škola s kapacitou 50, i když nevíme, zda aktuálně využívá 70 nebo 95 % kapacity.
A data jsou docela dobře rozložená. Když vezmu pouze skutečné vzdělávací školy a ne jídelny, družiny apod., vychází přibližně:
medián kapacity: 216
percentil: 600
percentil: přibližně 860
maximum: přes 4 000
To už umožňuje velmi rozumnou segmentaci například:
do 100, 101–250, 251–500, 501–800, 800+.
Nemusíme ji ale zatím natvrdo ukládat — můžeme mít číselnou kapacitu a rozsahy dělat filtrem.
Pozor na jednu důležitou věc: organizace ≠ jedna škola
To je asi nejpodstatnější vlastnost těch dat.
Například jedna právnická osoba může mít:
MŠ,
ZŠ,
školní jídelnu,
družinu.
A to všechno má stejné RED_IZO, ale různá IZO.
Proto Skoly.xlsx obsahuje 2 433 řádků proti pouze 1 044 organizacím.
Typický subjekt má 2 IZO. Některé mají 5, 6 nebo i 9 různých škol/zařízení.
Pro CRM ale nechceme:
Základní škola XY
Školní jídelna XY
Školní družina XY
jako tři zákazníky.
Chceme jeden Account:
Základní škola XY
a u něj například:
Typ školy: ZŠ
Další zařízení: družina, jídelna
Kapacita ZŠ: 620
To je jeden z hlavních důvodů, proč bych import připravil předem místo přímého importu některého z exportů.
Typ školy bych určitě zachoval
V datech je například:
457 subjektů provozujících MŠ,
321 subjektů provozujících ZŠ,
219 subjektů provozujících SŠ,
46 subjektů se ZUŠ,
35 subjektů s VOŠ,
8 subjektů s konzervatoří.
MŠMT používá kódy typu A00 = Mateřská škola, B00 = Základní škola, C00 = Střední škola atd.
V CRM bych ale uživateli vůbec neukazoval B00. Udělal bych z toho normální hodnoty:
MŠ | ZŠ | SŠ | VOŠ | ZUŠ | Konzervatoř | ...
A tady je důležitá volba: protože jedna organizace může být současně například MŠ + ZŠ + SŠ, nemělo by to být obyčejné dropdown pole s jednou hodnotou.
Buď multi-select, nebo několik boolean polí:
má_MŠ
má_ZŠ
má_SŠ
…
Pro hledání v CRM bych se přikláněl k booleanům. Pak se velmi pohodlně filtruje například:
ZŠ = ano
SŠ = ne
kapacita > 300
zřizovatel = obec
Obory jsou zajímavé, ale trochu jinak
SkolyAObory.xlsx obsahuje:
1 520 řádků,
585 právnických subjektů,
289 různých kódů oborů.
A to přesně odpovídá tomu, proč tento export nemůže být hlavním importem.
Pro jednu školu můžete mít například:
Informační technologie
Ekonomika a podnikání
Obchodní akademie
Veřejnosprávní činnost
Každý je samostatný řádek.
U ZŠ je většinou obor jen obecné Základní škola; u SŠ začíná být obor opravdu obchodně zajímavý.
Například v exportu je mimo jiné:
18-20-M/01 Informační technologie
63-41-M/01 Ekonomika a podnikání
63-41-M/02 Obchodní akademie
různé gymnaziální obory,
řemeslné obory atd.
Takže tady bych nedělal 289 polí v CRM.
Spíš bych měl dvě úrovně:
- Hrubá obchodní kategorie, například:
IT
technické
elektro
strojní
ekonomické
zdravotnické
pedagogické
gastronomie
gymnázium
…
- Původní seznam oborů, který si můžeme uložit jako text nebo do samostatné pomocné tabulky/modulu.
Pak půjde udělat filtr:
SŠ, kapacita > 400, obor IT nebo technický, Praha
což už může být obchodně opravdu zajímavý segment.
SkolyAMista.xlsx bych zatím skoro vůbec neimportoval
Ten soubor má 3 651 řádků a jde až na konkrétní místa poskytování vzdělávání.
Pro část organizací je míst více; některé školy jich mají opravdu hodně. Na úrovni jednotlivých IZO má více než jedno místo 586 škol/zařízení.
Ale pro první CRM bych je nerozepisoval.
V Account bych maximálně přidal:
Počet míst činnosti
To může být mimochodem další zajímavý signál velikosti/komplexity zákazníka.
Škola:
700 žáků, 5 budov
může mít z pohledu IT úplně jinou potřebu než:
700 žáků, jedna budova.
A teprve pokud se ukáže, že je to obchodně důležitý atribut, můžeme později vytvořit samostatný modul Locations.
Takže bych postavil jeden „master import“
Přibližně jeden řádek:
RED_IZO Název Zřizovatel MŠ ZŠ SŠ Kapacita Obory Počet míst Ředitel Email
600001083 ZŠ sv. Voršily církev ne ano ne 540 Základní škola 1 ... ...
A ten bych importoval jako 1 044 Accounts.
Neimportoval bych tedy Skoly.xlsx přímo. Použil bych ho jako zdroj pro obohacení Adresar.xlsx.
Totéž SkolyAObory.xlsx a SkolyAMista.xlsx.
Výsledný ETL je vlastně docela jednoduchý:
Adresar → 1 Account
podle RED_IZO
Skoly → GROUP BY RED_IZO
→ typy škol
→ vzdělávací kapacita
SkolyAObory → GROUP BY RED_IZO
→ seznam/kategorie oborů
SkolyAMista → GROUP BY RED_IZO
→ počet míst činnosti
A výsledek spojit zase přes RED_IZO.
A pak teprve scoring
Tady podle mě bude ta databáze opravdu užitečná.
Nemusíme se rozhodnout:
„Kterých 1 000 škol obeslat?“
Můžeme si postupně vytvořit segment.
Například jen hypoteticky:
velikost
500+ → zajímavější
250–499 → střední
pod 250 → menší
typ
ZŠ / SŠ → zajímavé
samotná MŠ → třeba méně zajímavá
zřizovatel
obecní
krajské
soukromé
církevní
obor
IT/technický → potenciálně jiné potřeby než běžná škola
komplexita
více míst činnosti
kombinace ZŠ + SŠ
více škol pod jednou organizací
Ale zatím bych nedělal jeden magický „score 0–100“. Nejdřív bych tato data dostal do CRM jako samostatná kritéria. Po prvních třeba 50–100 osloveních už můžeme zjistit, které atributy skutečně korelují s odpovědí nebo schůzkou, a scoring postavit na reálné zkušenosti.
Ještě jedna věc: ředitele bych v první fázi nevytvářel jako samostatný Contact. V exportu máme jeho jméno, ale e-mail a telefon jsou typicky kontakty organizace. Pro začátek bych Ředitel nechal jako pole Accountu. Contact bych zakládal až ve chvíli, kdy skutečně komunikujeme s konkrétní osobou.
Za mě tedy architektura první verze může být překvapivě jednoduchá: 1 044 Accounts + přibližně 15–20 dobře zvolených custom polí. Tím získáme vše potřebné k segmentaci, aniž bychom ze SuiteCRM udělali kopii školského rejstříku.