Współpraca IT-biznes w e-commerce B2B - jak nie utykać

Skąd konflikt

IT chce:

• Stabilności (no outages)
• Bezpieczeństwa (audyty, compliance)
• Predictability (planowane budget, znane technologie)
• Tech debt redukcji
• Quality (code review, testing)

E-com / biznes chce:

• Nowych funkcji (klient ich oczekuje)
• Szybkości (time-to-market)
• Eksperymentowania (A/B testing, MVPs)
• Mierzalnego ROI

Te są naturalnie w napięciu. „Nowa funkcja w 2 tygodnie" vs. „test + code review + security audit = 6 tygodni".

Governance - wspólny komitet sterujący

Steering Committee weekly (60 min):

• Manager e-com + IT Manager / CTO + ew. CMO / CFO
• Status inicjatyw
• Decyzje o priorytetach
• Eskalacje

Operations weekly (30 min):

• Manager e-com + Tech Lead
• Daily ops, blockers
• Tygodniowy plan

Strategic monthly (2h):

• Wszyscy stakeholders (zarząd jeśli relevant)
• Long-term roadmap
• Major decyzje (np. migration, new platforms)

Quarterly reviews (4h):

• Pełny review KPI
• OKRs revision
• Annual planning prep

Roadmap - zrównoważony

Częsty błąd: 100% nowe funkcje, 0% tech debt. Lub odwrotnie.

Zalecane proporcje:

• 60% nowe funkcje / inicjatywy biznesowe.
• 30% tech debt + utrzymanie + security.
• 10% bufor na emergencies / unplanned.

Tech debt to nie luksus. Brak inwestycji w tech debt = za rok wszystko wolne, niestabilne, bardziej kosztowne w utrzymaniu.

Komunikacja tech debt do zarządu:

• „Mamy 30% capacity na refactor X" - niezrozumiałe
• „Inwestycja w X uniknie awarii (typu Y kosztującej Z) i pozwoli na dodatkowe funkcje za 1.5×" - to mówi do zarządu

Priorytetyzacja - wspólna

Każda nowa inicjatywa = business case:

• Impact (jak duży wpływ)
• Effort (godziny dewelopera)
• Risk (jak ryzykowne)
• Strategic fit (czy zgodne ze strategią)

Scoring:

Priority = (Impact × Strategic_fit) / (Effort × Risk)

Proste, ale wymusza explicit dyskusję. Bez tego priorytetyzacja oparta na „kto głośniej krzyczy".

Shadow IT - ryzyko

Manager e-com frustrated z IT. Decyduje: „zatrudnimy własnego dewelopera, agency, postawimy własny system".

Shadow IT:

• Plusy: szybsze decyzje, dedykowane resources
• Minusy: brak integracji z głównym systemem, duplicate effort, security risk, brak governance

Lepsza opcja: rozmowa z IT o dedicated team / project. Nie ukrywać.

Vendor management

Wspólnie z IT:

Selection vendorów:

• IT ocenia tech (security, integracje, jakość kodu)
• Biznes ocenia business (cena, terminy, communication)
• Wspólna decyzja

Kontrakty:

• IT zaznacza security & compliance clauses
• Biznes zaznacza SLA, exit clause
• Wspólnie negocjują

Performance review:

• Co kwartał - KPI vendor (uptime, response time, jakość deliverables)
• Wspólne decyzje renew / replace

Konkretne praktyki, które pomagają

1. Wspólne OKRs. Manager e-com i IT manager dzielą część OKRs (np. „LCP < 2s na 80% stron"). Oboje są w tym razem.

2. Rotation. Programista spędza dzień z customer success. Customer success spędza dzień z dev team. Lepsze wzajemne zrozumienie.

3. Pre-mortem na inicjatywy. Przed startem dużej inicjatywy - sesja: „co może pójść źle?". IT i biznes razem identyfikują ryzyka.

4. Status updates raz w tygodniu. Krótka prezentacja statusu (każdy team 5 min). Wszyscy wiedzą co się dzieje.

5. Dedicated dev time. Reserved dni w tygodniu/sprincie dla tech debt. Bez tego - zawsze odwleczone.

Najczęstsze błędy

1. Manager e-com bypassing IT. „Sami to zrobimy" - kończy się katastrofą.

2. IT mówiące „nie" bez alternatyw. Każde feature request blocked. Frustration. Lepiej: „nie, ale można tak..." z alternative.

3. Brak regular sync. Komunikacja ad-hoc, eskalacje na escalation. Lepiej: regularne meetings.

4. Brak transparent prioritization. Każdy uważa że jego priorytet jest #1. Bez wspólnego procesu - chaos.

5. Vendor governance tylko po jednej stronie. Manager wybiera agency bez IT. IT robi audit bez konsultacji. Konflikty.

Co dalej

• Pillar zarządzania: Zarządzanie e-commerce B2B
• Roadmap: Roadmap e-commerce
• Budżet: Budżet e-commerce

Najczęstsze pytania