Jak napisać oświadczenie o problemie biznesowym – z przykładami

Oświadczenie o problemie biznesowym jest jedną z tych technik, które opisują powody inicjatywy ICT w praktycznych warunkach związanych z biznesem. Jest to opis aktualnie istniejącego problemu, który musi zostać rozwiązany i zapewnia kontekst dla problemów, które będą rozwiązywane.

Określenie problemu może być opisane w pojedynczym stwierdzeniu, po którym następuje rzeczywisty przykład w celu podkreślenia problemu. Podczas opracowywania zrozumienia problemów do rozwiązania należy myśleć w siedmiu szerokich obszarach przedstawionych poniżej.

Przykłady są podane dla każdej kategorii.

Kategorie stwierdzeń problemów biznesowych

1. Strategia

  • Niedostateczne dopasowanie do celów biznesowych.
  • Inicjatywy nie są obecnie dopasowane do ogólnej wizji.
  • Silne wdrażanie projektów.

2. Usługi / Produkty

  • Utrudnienia w świadczeniu usług z powodu nieterminowego pobierania informacji.
  • Niska responsywność w angażowaniu leadów sprzedażowych z powodu nieterminowego pobierania informacji
  • Wysoki poziom zwrotów produktów z powodu błędów popełnionych na zamówieniach sprzedaży.

3. Ludzie

  • Nieodpowiednie szkolenie pracowników i/lub brak możliwości wsparcia przez pracowników obszarów działalności doświadczających wąskich gardeł.Źle zdefiniowane role i obowiązki powodują zamieszanie i słabą zdolność reagowania na potrzeby operacyjne.
  • Niedostateczne dostarczanie usług ze względu na możliwości personelu i problemy szkoleniowe.

4. Procesy

  • Mnóstwo powielonych procesów biznesowych i aplikacji.
  • Intensywne przetwarzanie ręczne ze względu na fizyczną obsługę papierkowej roboty, wysyłanie poczty i ręczną koordynację wydarzeń.
  • Podwójne wprowadzanie danych i ręczne utrzymywanie danych w arkuszach kalkulacyjnych lub osobistych bazach danych.

5. Aplikacje

  • Niedostatecznie rozwinięta funkcjonalność z powodu nieodpowiedniego zdefiniowania wymagań biznesowych i funkcjonalnych.
  • Nieaktualna funkcjonalność spowodowana stale zmieniającym się klimatem biznesowym.
  • Małe lub żadne wsparcie aplikacji z powodu zastrzeżonego lub nadmiarowego oprogramowania.

6. Informacje

  • Niestrukturalne informacje i treści przechowywane na różnych urządzeniach, co bardzo utrudnia wyszukiwanie i odzyskiwanie.
  • Brak metadanych dołączonych do informacji, co utrudnia wyszukiwanie i odzyskiwanie.
  • Różne metody kodowania tych samych typów zbiorów danych w różnych repozytoriach.

7. Infrastruktura

  • Niewiele wiadomo o wszystkich systemach, co utrudnia strategiczną koordynację utrzymania.
  • Wiele aplikacji jest obsługiwanych przez wiele systemów tworząc niepotrzebne koszty utrzymania poprzez wspieranie zduplikowanych systemów.

Kiedy już zrozumiesz problemy, opisz ryzyko związane z każdym z nich, aby w pełni podkreślić potencjalny wpływ na biznes (np, koszty, nieefektywność i utracone możliwości).

Przykład opisu problemu

Poniżej znajduje się przykład opisujący opis problemu, opis i związane z nim ryzyko dla wysoce ręcznego procesu biznesowego, który można łatwo rozwiązać za pomocą technologii.

Opis problemu: Intensywne przetwarzanie ręczne ze względu na fizyczną obsługę dokumentów.

Opis: Formularze urlopu rocznego są zazwyczaj wypełniane przez Pracownika, drukowane, wysyłane do Kierownika/Pełnomocnika w celu zatwierdzenia, wysyłane do Działu Kadr w celu weryfikacji i wprowadzenia danych, skanowane i przesyłane do EDRMS, a następnie wysyłane do Płac w celu (ponownego) wprowadzenia danych.

Ryzyko: Ten wysoce ręczny scenariusz prowadzi do „wąskich gardeł” w świadczeniu usług i zwiększa ryzyko słabej reakcji organizacji na potrzeby biznesu oraz utraty czasu, który powinien być poświęcony na prowadzenie podstawowej działalności.

Jak opracować opis problemu

Aby opracować opis problemu i związane z nim ryzyko projektu, należy nawiązać współpracę z menedżerami i ekspertami w odpowiednich obszarach biznesowych. Zadaj im pytania specyficzne dla każdej z sześciu kategorii opisanych powyżej, aby wydobyć szczegóły dotyczące tego, gdzie leżą problemy. Strategia ta może być wdrożona w początkowych fazach tworzenia i analizy projektu, niezależnie od stosowanej metodyki (np. Agile lub Waterfall). Jest ona przydatna przy opracowywaniu mandatów projektowych i przypadków biznesowych.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *