Kiedy należy zbudować własną aplikację biznesową zamiast zakupu oprogramowania?

Wybierz pomiędzy zakupem, integracją i budową

Decyzja build- versus- buy rzadko jest binarna. Zazwyczaj istnieją trzy opcje: przyjąć i skonfigurować produkt, połączyć lub rozszerzyć istniejące systemy, lub utworzyć ukierunkowany aplikacji. Traktowanie integracji jako odrębnej opcji ma znaczenie, ponieważ wiele przedsiębiorstw już posiada większość niezbędnych im możliwości; niepowodzenie leży w przepaści między systemami, zespołami lub decyzjami.

Napisz jedno zdanie dla każdej opcji. Określić, co zmieni się dla użytkownika, które systemy pozostają autorytatywne, kto będzie właścicielem usługi i jakie ryzyko pozostaje. Jeśli zespół nie może wyjaśnić opcji bez nazwy kilkudziesięciu funkcji, problem nie jest jeszcze wystarczająco jasny, aby uczciwie porównać.

• Kupuj i konfiguruj, gdy proces jest standardowy, a zachowanie wspomagane przez vendorę jest akceptowalne.
• Integracja lub rozszerzenie, gdy istniejące systemy obejmują pracę podstawową, ale dane i decyzje nie przemieszczają się bezpiecznie między nimi.
• Zbuduj, gdy przepływ pracy jest specyficzny, cenny i wystarczająco stabilny, aby uzasadnić usługi własne.

Zacznij od problemu użytkownika i wymiernego wyniku

Zacznij od ludzi wykonujących lub otrzymujących pracę. Obserwuj, gdzie czekają, zmieniaj dane, goń za zatwierdzeniem, poprawiaj błędy lub trać dowody. GOV. UK Service Standard zaczyna się od zrozumienia użytkowników i problem w pełnym kontekście, następnie prosi zespoły do określenia, jak sukces wygląda i publikuje dane wydajności. Zasada ta ma również zastosowanie do komercyjnego narzędzia back-office.

Zmienić obserwację w wynik, który może być przetestowany. Zamiast "potrzebujemy aplikacji na cytaty", "używać" doradca handlowy może zebrać technicznie poprawny cytat, uzyskać wymagane zatwierdzenie marży i pokazać dowody bez kopiowania danych produktu między trzema arkuszami kalkulacyjnymi ". Dodać punkt odniesienia, taki jak upływający czas, szybkość przerabiania, zaległości w wyłączeniach lub liczba ręcznych instrukcji obsługi.

Żądanie funkcji opisuje proponowaną odpowiedź. Wynik użytkownika opisuje wynik, który każda opcja musi udowodnić. Utrzymanie tych odrębnych elementów uniemożliwia podjęcie decyzji o projekcie przed przetestowaniem rzeczywistych potrzeb.

Sprawdź, czy proces jest na tyle stabilny, aby zautomatyzować

Oprogramowanie sprawia, że proces jest powtarzalny; nie sprawia, że nierozwiązana polityka jest spójna. Jeśli dwóch menedżerów stosuje sprzeczne zasady zatwierdzania, zmienia tożsamość produktu pomiędzy plikami lub nikt nie wie, który rekord jest autorytatywny, kodowanie obecnego zachowania może sprawić, że nieporozumienia szybciej i trudniej zobaczyć.

Mapa wyzwalacza, użytkowników, wejść, decyzji, wyjątków i zakończony wynik. Przepuść kilka prawdziwych spraw przez mapę, włącznie z niezręcznymi. Zaznacz, gdzie osoba używa osądu i gdzie reguła jest rzeczywiście powtarzalna. Jeśli proces zmienia się co tydzień, ponieważ firma nadal się uczy, należy użyć lekkiego próbnego i poprawić proces przed zobowiązaniem się do trwałej budowy.

• Zapalnik i zakończony wynik są jednoznaczne.
• Osoby odpowiedzialne za każdą decyzję są nazwane.
• Ważne dane mają znane źródło i stały identyfikator.
• Wspólne wyjątki mogą być uznawane i kierowane bezpiecznie.
• Zespół zgadza się, co musi być zalogowane, zweryfikowane lub zatwierdzone.

Test off - półka pasuje do prawdziwej pracy, a nie listy funkcji

Długa lista funkcji może ukryć słabe dopasowanie operacyjne. Stworzyć mały zestaw reprezentatywnych scenariuszy i poprosić każdego dostawcy do wykazania ich przy użyciu realistycznych ról, rekordów i wyjątków. Należy uwzględnić przypadek rutynowy, przypadek wrażliwy na uprawnienia, korektę, niepowodzenie integracji oraz przypadek wyjścia lub wywozu danych.

Ocena wyniku wobec must-have wyniki, a nie liczba dostępnych ustawień. Sprawdzić tożsamość, własność danych, uprawnienia, dowody audytowe, dostępność, sprawozdawczość, granice integracji, odzysk i wsparcie. Brak funkcji wygodnej może być tolerowany; nie jest to działanie, które łamie tożsamość produktu lub obejście zatwierdzenia.

Sprawdź również koszt dostosowania firmy. Zmiana nieszkodliwego preferencji w celu dopasowania wspieranego przepływu pracy może być rozsądna. Zmuszanie bezpieczeństwa, zgodności lub obietnic klienta do modelu ogólnego może przenieść koszty z budżetu oprogramowania na błędy, nadzór i ręczne pojednanie.

Kup, gdy zdolność jest wspólna i wsparcie ma największe znaczenie

Kupno jest zazwyczaj lepszym wyborem, gdy wiele organizacji wykonuje tę samą pracę w podobny sposób, produkt sprzedający spełnia krytyczne scenariusze, a regularne aktualizacje, dokumentacja i wsparcie są cenniejsze niż unikalne zachowanie. Wypłata, sprzedaż towaru i podstawowa współpraca w zakresie dokumentów często odpowiadają temu wzorowi, chociaż dokładna ocena nadal zależy od działalności.

Potwierdź model operacyjny przed podpisaniem. Określić granice konfiguracji, możliwość przenoszenia danych, uwierzytelnianie, uprawnienia, poziomy usług, polityka aktualizacji, czynniki cenowe, wysiłek migracyjny i droga na zewnątrz. Kodeks Praktyki Technologicznej zaleca zdefiniowanie potrzeb użytkowników, dokonanie świadomego wyboru strategii zakupów, stosowanie w miarę możliwości otwartych standardów oraz uwzględnienie pełnego cyklu życia technologii.

Integracja lub rozszerzenie, gdy systemy bazowe już działają

Przedsiębiorstwo może już posiadać ERP, który posiada akcje i ceny, CRM, który posiada możliwości i platformę ecommerce, która posiada checkout. Wymiana którejkolwiek z nich w celu naprawienia uszkodzonego uchwytu może spowodować większe ryzyko niż usunięcie. Regulowana integracja lub niewielka warstwa przepływu pracy może zachować systemy rekordów przy jednoczesnym usprawnieniu podróży między nimi.

Opcja ta nadal wymaga wyraźnych granic. Zdefiniuj autorytatywny identyfikator i właściciela dla każdego ważnego pola, kierunek każdej aktualizacji, sposób postępowania z duplikatami lub opóźnieniami, które ustały podczas przetwarzania i jak osoba rozwiązuje wyjątek. Cienki interfejs użytkownika nad niejasną własnością nie jest strategią integracji.

Budowanie, gdy przepływ pracy tworzy wartość charakterystyczną

Niestandardowa aplikacja staje się wiarygodna, gdy przepływ pracy w istotny sposób wpływa na dochody, koszty, ryzyko lub doświadczenie klienta; często powtarza się wystarczająco często, aby uzasadnić zmiany; i nie może być dobrze wspierany bez uszkodzenia pracownic. Specyficzny stosunek danych, uprawnienia, wymogi dowodowe lub ścieżki decyzyjne mogą spowodować, że produkt generyczny nie będzie w stanie dopasować się do danego produktu.

Custom nie oznacza wymiany każdej platformy. Najbardziej użyteczną aplikacją może być usługa ukierunkowana, która łączy zatwierdzone systemy i reguluje jeden ważny wynik. M.I.A.I Builder jest zaprojektowany, aby przekształcić zwykły angielski wniosek o aplikację i ukierunkowane wyjaśnienie w regulowaną, przeglądalną ścieżkę aplikacji, z weryfikacji i kontrolowane dostawy wbudowane w podejście.

Ostatecznym warunkiem jest własność. Nazwa osoby lub zespołu musi posiadać priorytety, dostęp, jakość danych, wsparcie, decyzje o zmianie i emeryturę. Jeżeli nikt nie będzie obsługiwał usługi po uruchomieniu, organizacja nie zdecydowała się na budowę; postanowiła zgromadzić niezarządzaną zależność.

Porównaj całkowity koszt cyklu życia, a nie cenę licencji w porównaniu z ceną budowy

Sprawiedliwe porównanie obejmuje ten sam horyzont czasowy i ten sam wynik. W przypadku zakupionego produktu, w tym odkrycie, licencje, konfigurację, partnerów wykonawczych, migrację, integrację, szkolenia, wsparcie, zmiany cen sprzedawców i wyjście. W przypadku aplikacji niestandardowych, obejmują odkrywanie, projektowanie, rozwój, testowanie, hosting, monitorowanie, pracę w zakresie bezpieczeństwa, wsparcie, udoskonalenie, dokumentację i ewentualną likwidację.

Koszty zapisu, które są łatwe do ukrycia: powtarzające się ręczne pojednanie, podwójne wejście, opóźnienia w zatwierdzeniu, nieudany import, nadzór i koszt alternatywny osób pracujących wokół oprogramowania. Nie przekształcaj każdej korzyści w pewną liczbę finansową. Utrzymanie założeń na widoku, wykorzystanie zakresu, w którym dowody są niepewne i aktualizacja sprawy po pilocie.

• Nabycie i wstępne wykonanie
• Migracja danych i integracja
• Szkolenia, adopcja i zmiana procesu
• Bezpieczeństwo, prywatność, dostępność i pewność
• Hosting, monitorowanie, wsparcie i odzyskiwanie incydentów
• Aktualizacje, wnioskowane zmiany i przepływ cen dostawców
• Eksport danych, przejście na emeryturę i przejście na emeryturę

Zapewnienie bezpieczeństwa, prywatności i dostępności

Nie są to dodatki do dodania po wybraniu opcji. Identyfikacja wrażliwych danych, zatrzymywanie, role dostępu, uwierzytelnianie, potrzeby w zakresie audytu, oczekiwania w zakresie odzyskiwania oraz wymogi dostępności podczas oceny. Produkt, który nie może sprostać kontroli niezbywalnej, nie jest najtańszą opcją, niezależnie od ceny głównej.

NIST zaleca włączenie praktyk bezpieczeństwa w całym cyklu rozwoju oprogramowania zamiast traktować je jako ostateczną kontrolę. Zakupione oprogramowanie również wymaga należytej staranności: zrozumieć, w jaki sposób dostawca rozwija i aktualizuje je, jakie dowody są dostępne, jak postępować z słabościami i które obowiązki pozostają z Twojej organizacji.

Korzystanie z niezbędnego minimalnego dostępu, oddzielenie zatwierdzenia od wykonania, jeżeli wymaga tego ryzyko, oraz dokonanie znaczących działań. W przypadku prac niestandardowych należy uwzględnić te warunki w testach akceptacji. W przypadku zakupionego oprogramowania należy uwzględnić je w ocenie, kontrakcie i bieżącym przeglądzie.

Decyduj kto będzie właścicielem i obsługą usługi

Przed zatwierdzeniem rozwiązania należy wymienić właściciela usługi. Osoba ta nie musi pisać kodu, ale musi być w stanie priorytetowo traktować wyniki, akceptować lub odrzucać zmiany, koordynować decyzje o incydentach i potwierdzić, kiedy usługa jest nadal warta działania. Własność produktu nie może się zakończyć po zakończeniu wdrażania.

Określ trasę wsparcia, godziny obsługi, monitorowanie, tworzenie kopii zapasowych i odzyskiwanie, eskalację dostawców, przeglądy dostępu, zatwierdzanie wydania i dokumentacja. Zgadzam się, jak pilne poprawki różnią się od planowanych ulepszeń. Te zobowiązania operacyjne często pokazują, że obiecujący prototyp nie jest gotowy do stania się usługą o krytycznym znaczeniu dla biznesu.

Konkretny przykład: regulowany strumień aprobaty

Rozważ dystrybutora technicznego, którego zespół handlowy przygotowuje notowania na części zamienne. Doradca musi zidentyfikować zakres maszynowy i szeregowy klienta, wybrać kompatybilny produkt, sprawdzić bieżącą cenę i dostępność, zastosować zatwierdzoną zasadę marży, uzyskać zatwierdzenie menedżera dla wyjątków i zachować wykorzystane dowody. Dzisiaj praca przecina ERP, CRM, pliki produktów, e-mail i arkusze kalkulacyjne.

Zakup nowego CRM nie rozwiązuje logiki produktu i zatwierdzania, a zastąpienie ERP stanowiłoby niepotrzebne ryzyko dla zapasów i cen. Ogólny produkt Workflow może przemieszczać zadania, ale nie może udowodnić wymaganej relacji produktu bez obszernych zadań. W związku z tym zespół decyzyjny utrzymuje ERP i CRM, następnie ocenia skoncentrowaną aplikację, która czyta zatwierdzone rekordy, prowadzi doradcę poprzez decyzję i odpisuje status cytatu bez zmiany autorytatywnego produktu lub ewidencji towarowej.

Pierwsze wydanie obejmuje jedną rodzinę produktów, jeden zespół sprzedaży i dwa wyniki zatwierdzenia. Posiada stabilne identyfikatory źródłowe, rejestruje wersję zasad i dowody, blokuje niepotwierdzone oświadczenie o zgodności i wysyła wyjątki do o nazwie recenzenta. Środki pilotażowe upłynęły od czasu cytowania, przepracowania, wieku wyjątkowego i korekt po zatwierdzeniu. Dowody te decydują o przedłużeniu, zmianie lub zatrzymaniu.

Uruchom najmniejszy pilot, który może obalić pomysł

Przydatny pilot nie jest kolekcją atrakcyjnych ekranów. Bierze on prawdziwy przypadek od początku do regulowanego wyniku z faktycznymi rolami, danymi reprezentatywnymi, wyjątkiem i ścieżką odzyskiwania. Jego celem jest ujawnienie słabych założeń, zanim organizacja je wyskaluje.

Wybierz wąską grupę użytkowników i ograniczony typ transakcji. Określić warunki początkowe i przejść wcześniej. Włączanie użyteczności, dokładności danych, uprawnień, dostępności, wsparcia operacyjnego i obsługi awarii. Jeśli pilot nie otrzyma wyniku, sprawdź dlaczego zamiast automatycznie dodawać funkcje.

M.I.A.I Builder zaczyna się od prostego pytania, zadaje skoncentrowane pytania, które wpływają na wynik i utrzymuje tworzenie regulowane i odwracalne. To może pomóc przedsiębiorstwu przejść od szerokiego pomysłu do ścieżki testable aplikacji, ale firma musi nadal dostarczyć wiedzy procesu, właścicieli, decyzje dotyczące danych i dowody sukcesu.

1. Zapisz wynik użytkownika, podstawowe i niezbywalne kontrole.
2. Należy wybrać przypadki reprezentatywne, w tym co najmniej jeden wyjątek.
3. Zbuduj lub skonfiguruj najmniejszy kompletny przepływ pracy.
4. Sprawdź z ludźmi, którzy wykonują prawdziwą pracę i ją wspierają.
5. Porównaj wyniki z wartościami wyjściowymi i odnotuj nierozwiązane zagrożenia.
6. Wybierz adopcję, zmienić kierunek lub zatrzymać.

Użyj rekordu decyzji zamiast punktacji jednokierunkowej

Ważony wynik może pomóc zespołom porównać opcje, ale ostateczna liczba może ukryć nieudany wymóg. Prowadzenie krótkiego rejestru decyzji, który zawiera listę dowodów dla użytkowników, musi mieć wyniki, przetestowane scenariusze, założenia, koszty, ryzyko, odrzuconych opcji, właściciela i datę przeglądu. Zaznacz warunki niezbywalne oddzielnie od preferencji.

Przegląd decyzji, kiedy wielkość transakcji, przepisy, warunki dostawcy, podstawowe systemy lub użytkownik potrzebuje zmiany. Zakup dzisiaj nie uniemożliwia budowy później; skoncentrowany niestandardowy przepływ pracy nie uzasadnia zastąpienia platformy wokół niego. Celem nie jest obrona pierwotnego wyboru na zawsze, ale utrzymanie usługi użytecznej, bezpiecznej i ekonomicznie rozsądnej.

• Jaki problem użytkowników i wymierne rezultaty rozwiązujemy?
• Która opcja przeszła każdy niepodlegający negocjacjom scenariusz?
• Od jakich danych, uprawnień i systemów zależy?
• Co obejmuje i wyklucza zakres kosztów cyklu życia?
• Kto jest właścicielem operacji, wsparcia, zmiany i emerytury?
• Jakie dowody skłoniłyby nas do ponownego rozpatrzenia lub odwrócenia decyzji?