Przegląd zaczyna się od procesu. Siadamy przy osobach, które go prowadzą, i patrzymy, gdzie każdy krok się zaczyna, w którym programie kończy i ile razy te same dane ktoś wpisuje ręcznie. Każde miejsce, w którym praca czeka, zapisujemy z przyczyną: ustawienie systemu, brak połączenia, brak funkcji albo sposób pracy, którego żaden system nie naprawi.
Potem zaglądamy do środka każdego systemu. Spisujemy jego wersję, osobę, która go utrzymuje, i koszt licencji, czyli prawa do korzystania z programu. Ustalamy, gdzie leżą dane o klientach, zamówieniach i rozliczeniach, który system jest ich źródłem i gdzie te same dane leżą w dwóch miejscach. Oglądamy integracje, czyli połączenia, którymi systemy same wymieniają dane, i wypisujemy wymiany, które zamiast połączenia mają człowieka z arkuszem.
Sprawdzamy też to, o co zarząd rzadko pyta. Dostęp administratora, czyli pełną władzę nad systemem: kto go ma i czy ta osoba nadal pracuje w firmie. Kopię zapasową, czyli zapis danych na wypadek awarii: czy istnieje i czy ktoś kiedykolwiek odtworzył z niej dane. Wersję systemu: czy ma jeszcze wsparcie producenta. Umowę z dostawcą: co mówi o zmianach i o danych po jej zakończeniu. Kod źródłowy oprogramowania pisanego na zamówienie, czyli tekst programu, bez którego nikt poza autorem nie wprowadzi zmian: czy firma go ma.
Z przeglądu powstaje opis stanu obecnego w trzech listach: co działa i zostaje, co hamuje pracę i z jakiej przyczyny, co da się wykorzystać bez nowego systemu. Na jego podstawie piszemy rekomendację z zakresem: jedna droga i lista prac w kolejności, także gdy tą drogą jest zmiana ustawień albo sposobu pracy. Harmonogram wdrożenia to osobny zakres: plan wdrożenia krok po kroku.