Zakres działalności

Dla kogo: dla firm, w których zespół pracuje we wspólnym arkuszu, a arkusz zaczyna przeszkadzać: ktoś nadpisuje cudze zmiany, ktoś liczy na starej wersji, a całość rozumie już tylko autor. Inne sygnały i to, kiedy warto przy arkuszu zostać, opisujemy w artykule Kiedy arkusz przestaje wystarczać.

Co dostajecie: aplikację w przeglądarce, na komputerze i na telefonie, z waszymi formułami i danymi. Dochodzi to, czego arkusz nie zapewnia: praca wielu osób na tych samych danych, uprawnienia, obieg i akceptacje oraz historia zmian.

Applanter to nasza platforma. Dziś aplikacje przygotowujemy na niej sami, jako partner wdrożeniowy: CRM, oferty i zamówienia czy obieg faktur. Budujemy aplikację z waszego arkusza i sposobu pracy, razem z przeniesieniem danych. Formuły pisze się w niej tak jak w arkuszu, po polsku, a formularze, etapy, obiegi i reguły platforma zapisuje w otwartych standardach. Edytor, w którym firma sama zbuduje kolejne aplikacje, udostępnimy później. Terminu dziś nie podajemy.

Dane są wasze. Listy i zestawienia można w każdej chwili wyeksportować do arkusza, a pełne dokumenty, z pozycjami i powiązaniami, w pełnym zapisie, który zachowuje ich budowę. Po zakończeniu abonamentu zabieracie dane w postaci tabel oraz definicję i konfigurację aplikacji w otwartych standardach, więc aplikację może dalej prowadzić ktoś inny.

Dla kogo: dla firm, których proces jest nietypowy albo stanowi o ich przewadze i nie zmieści się w gotowej platformie.

Co dostajecie: aplikację webową dopasowaną do waszego procesu, z testami i dokumentacją. Kod i dane należą do was od pierwszego dnia i przez cały projekt macie do nich dostęp. Formularze, procesy i reguły zapisujemy w otwartych standardach tam, gdzie takie standardy istnieją. Części wspólne dla wielu projektów, czyli nasze biblioteki, dostajecie z licencją, która pozwala używać ich w waszej instalacji.

Typowe przykłady to obieg dokumentów i akceptacji, ewidencje, panele dla zespołu i klientów oraz raporty. Aplikację budujemy na pojęciach, którymi posługuje się firma. Tam, gdzie reguły często się zmieniają albo wymiana dostawcy jest prawdopodobna, oddzielamy reguły firmy od połączeń z dostawcami, żeby zmiana dostawcy płatności nie wymagała przepisywania reguł. Prosty panel do poprawiania opisów zostaje prosty, bo tam taki podział się nie opłaca. Szerzej piszemy o tym w artykule Zmiana dostawcy bez przepisywania aplikacji.

Dla kogo: dla firm, w których ktoś przepisuje dane z jednego systemu do drugiego albo eksportuje je do arkusza tylko po to, żeby wkleić je gdzie indziej.

Co dostajecie: połączenia, które przenoszą dane same, i powtarzalne zadania, takie jak importy, raporty i przypomnienia, uruchamiane automatycznie.

Łączymy na przykład sklep internetowy z programem księgowym, aplikację z bankiem, żeby wyciągów ani płatności nie trzeba było wpisywać ręcznie, i program do faktur z KSeF. Czy połączenie z danym dostawcą zamknąć w osobnej części programu, zależy od tego, jak prawdopodobna jest jego wymiana. Tam, gdzie dostawca może się zmienić, jego zmiana dotyczy wtedy jednego miejsca, a reszta systemu zostaje.

Dla kogo: dla firm, które potrzebują strony łatwej do edycji i utrzymania.

Co dostajecie: stronę na systemie dobranym do waszej sytuacji, z przekazaną edycją treści i treścią, którą da się odtworzyć i przenieść.

WordPress sprawdza się, gdy liczy się popularny panel edycji i duży wybór gotowych rozszerzeń. Wagtail wybieramy, gdy strona ma nietypową strukturę treści, łączy się z aplikacją firmy albo ma rosnąć razem z nią. Na Wagtailu działa też ta strona: jej treść jest zapisana razem z kodem, więc każdą wcześniejszą wersję da się odtworzyć. Stronę budowaną od podstaw projektujemy według międzynarodowych wytycznych dostępności (WCAG 2.2) na poziomie AA. Przy stronie na gotowym motywie sprawdzamy dostępność i poprawiamy to, co się da. Dbamy też o rzeczy, których odwiedzający nie widzi, a które decydują o bezpieczeństwie: adres e-mail ukryty przed robotami zbierającymi adresy i przeglądarkę, która uruchamia tylko skrypty samej strony.

Po wdrożeniu możemy utrzymywać system (aktualizacje, kopie zapasowe, monitoring) albo przekazać go waszemu działowi IT lub innemu wykonawcy, z dokumentacją.

Błędy i prośby o zmiany zgłasza się w jednym, ustalonym miejscu. Czas reakcji na zgłoszenia i awarie ustalamy w umowie, w zależności od tego, jak ważny jest system dla firmy. Błędy w odebranej wersji poprawiamy bez dopłaty przez okres ustalony w umowie. Zmianę najpierw opisujemy i wyceniamy, a robimy po waszej akceptacji.

Dokumentację projektu macie u siebie na bieżąco, a hasła do kont i usług, które zakładamy w waszym imieniu, przekazujemy wam. Przy aplikacji na zamówienie macie też dostęp do kodu, a przy Applanterze definicję aplikacji w otwartych standardach, więc projekt może przejąć ktoś inny. Dlaczego to ważne, piszemy w artykule „U mnie działa”.

W czym pracujemy i według jakich standardów. Dlaczego to ważne dla firmy, opisujemy po ludzku w artykule Standardy, których nie widać.