Kami terus berbicara tentang bagaimana kami meningkatkan kehidupan tidak hanya pelanggan dan mitra kami, tetapi juga karyawan perusahaan. Ini akan tentang implementasi sistem harmonisasi. Saya sengaja tidak menunjukkan koordinasi "apa", karena di masa depan akan menjadi jelas bahwa, murni secara teoritis, koordinasi "segalanya".
Refleksi pada sistem persetujuan
Awalnya, di perusahaan kami, dan juga di banyak perusahaan lain, di mana saya harus bekerja, dan di mana saya menjadi "tamu" atau baru saja mendengar dari teman-teman saya, perjanjian dinegosiasikan (dan pada saat penulisan artikel ini masih berlangsung), dengan cara korespondensi reguler di surat. Secara alami, ini sesuai dengan perusahaan dengan sejumlah kecil personil dan kontraktor. Tidak ada kebutuhan khusus untuk membuat dan menerapkan sistem karena penandatanganan satu atau dua perjanjian per bulan (atau bahkan satu tahun) dengan CEO sendiri yang mengambil keputusan untuk menandatangani. Situasi serupa juga terjadi pada pembayaran tagihan. Setiap karyawan yang berinteraksi dengan rekanan dan perlu membayar sesuatu, meminta faktur dan mengirimkannya ke departemen akuntansi melalui surat dengan permintaan untuk "membayar". Pada saat yang sama, akuntansi tidak selalu membayar tagihan tanpa persetujuan pembayaran sebelumnya dengan atasan langsung dari karyawan dan / atau manajemen perusahaan. Dalam kondisi tertentu, rantai persetujuan dapat "dipersingkat" atau sebaliknya "diperpanjang".
Sejauh ini tidak ada banyak karyawan dan semua orang tahu semua rekan mereka siapa dan siapa pemimpinnya - tidak ada masalah khusus. Dalam mode manual dan dalam kondisi tertentu, aplikasi untuk pembayaran dinegosiasikan dalam mode korespondensi dan dibayar (atau ditolak). Tetapi perusahaan kami berkembang dan dari saat tertentu kami melewati garis yang tak terlihat itu, setelah itu perlu dipikirkan otomatisasi proses ini dan kebutuhan untuk memperkenalkan sesuatu yang baru.
Daftar Keinginan kami
Kami memiliki persyaratan sistem minimum kami sendiri:
- Antarmuka yang ramah pengguna dan berorientasi web yang sangat diinginkan (tanpa perlu menginstal klien)
- Fleksibilitas konfigurasi
- Meskipun kami tidak klinis, kami paranoid. Oleh karena itu, kami ingin menjaga layanan di mana informasi rahasia dapat muncul dalam batas tertutup kami
Awalnya, kami menganalisis produk-produk dari keluarga "sistem manajemen dokumen elektronik" yang ada di pasaran. Kami melihat sistem yang terkenal: 1C: Manajemen Dokumen, "BISNIS", "INI". Kami juga melihat sistem yang dibuat sesuai pesanan untuk perusahaan lain, serta produk baru seperti Allware.
Saya tidak bisa mengatakan bahwa sistemnya buruk. Faktanya, hampir semua sistem memungkinkan kita untuk memenuhi Daftar Keinginan utama kita dan bahkan lebih dari yang kita butuhkan. Tetapi, seperti biasa, iblis ada dalam perinciannya.
Pertama-tama - antarmuka. Kami tidak terbiasa menggunakan antarmuka gaya "1C". Kami membutuhkan antarmuka yang sederhana dan intuitif di mana kami akan melakukan tindakan minimum untuk mendapatkan hasil maksimal (dan siapa yang tidak mau?).
Kedua, harga (dibayar pada waktu bersamaan dan kemudian biaya kepemilikan produk secara keseluruhan). Kami tidak membutuhkan semua yang ada di sistem yang ditawarkan di luar kotak. Tetapi pada saat yang sama Anda harus segera membayar untuk semuanya. Dan karena banyak yang kini beralih ke sistem berlangganan, Anda harus membayar terus-menerus dan jumlahnya, seperti biasa, tergantung pada banyak kondisi (jumlah pengguna / koneksi, kemampuan untuk bekerja di cloud, opsi tambahan, modul, dll.). Dan untuk "melompat" sistem, jika tiba-tiba harga tidak lagi sesuai - bermasalah.
Ketiga, tidak ada cara untuk "mengelola" "Wishlist" Anda.
Implementasi
Saya tidak akan menulis tentang bagaimana dan mengapa pada akhirnya kami memutuskan untuk "datang dengan sepeda" dan menulis sistem manajemen dokumen elektronik kami sendiri. Keputusan telah dibuat - untuk dilakukan. Kami sudah melalui penyakit mencoba menerapkan produk tanpa persyaratan, sehingga proses penulisan TK dan harmonisasi dimulai pertama kali. Untungnya, di depan mata kami, kami memiliki contoh implementasi, sehingga formasi berjalan cukup tanpa rasa sakit.
Satu-satunya hal yang kami harus hancurkan tombak adalah bahwa dalam proses pengembangan arsitektur kita tidak boleh menyerah pada godaan untuk memenuhi persyaratan "sebagaimana adanya", dengan merusak fleksibilitas dan kemudahan penggunaan lebih lanjut. Godaan itu hebat, terutama bagi pelanggan utama, karena periode implementasi dan implementasi akan berkurang sebanyak 2 kali. Tetapi kami berhasil meyakinkan manajemen dan diri kami sendiri bahwa "lebih baik kehilangan satu hari, kemudian terbang dalam 5 menit". Dan saya pikir kami membuat pilihan yang tepat.
Lebih baik kehilangan sehari, kemudian terbang dalam 5 menit.
Tumpukan "standar" adalah .Net Core 2 dan EntityFramework, Angular 4, MS SQL, karena kami memiliki latar belakang yang agak besar dalam penerapan alat dan teknologi. Meskipun DBMS tidak terlalu penting bagi kami karena alasan yang jelas. Jika perlu, mari beralih ke apa pun yang kita inginkan.
Hasilnya adalah produk yang memenuhi persyaratan penting bagi kami:
- Satu alur kerja - berbagai pihak dalam perjanjian (terkait dengan paragraf berikutnya)
- Kondisi untuk melewati tahap persetujuan dalam kondisi tertentu (bidang apa pun dalam aplikasi dapat ditambahkan ke kondisi dengan cek yang diberikan dan, berdasarkan validitas kondisi, kebutuhan untuk pergi ke langkah persetujuan berikutnya atau "melewatkan" ditentukan)
- Antarmuka "eksklusif" kami
Fitur yang mudah dan bermanfaat seperti:
- Menetapkan nilai default untuk direktori (baik pengguna dan sistem). Panduan pengguna adalah entitas yang memungkinkan pengguna untuk mengatur item sendiri. Item yang dibuat hanya akan tersedia baginya. Pada saat yang sama, dalam direktori seperti itu, administrator sistem dapat memasukkan elemen umum yang akan tersedia untuk semua pengguna sistem
- Menentukan elemen direktori yang paling sering digunakan untuk setiap pengguna dan membentuk daftar di antarmuka berdasarkan statistik ini (pengurutan)
- Dapat dikustomisasi sepenuhnya dari diagram panel admin (struktur dan properti bidang yang harus diisi) dan tampilan (pengaturan elemen dalam bentuk) dari setiap jenis permintaan persetujuan
- ACL fleksibel
- Setiap pengguna mencari aplikasi yang dapat disesuaikan dengan berbagai set parameter. Parameter dapat berupa properti templat aplikasi dengan kemampuan untuk memilih kondisi yang harus dibebankan pada bidang ini selama pemfilteran. Dalam hal ini, Anda bisa membuat banyak set untuk pemfilteran. Nyaman untuk pencarian cepat di berbagai bagian
- Validasi nilai yang dimasukkan berdasarkan pada template yang diberikan untuk bidang aplikasi tertentu
Tentu saja, ada beberapa "keingintahuan" juga. Pertama-tama, kita berbicara tentang mengkonfigurasi alur kerja. Kami awalnya memutuskan bahwa kami membutuhkan kemampuan untuk mengonfigurasi diagram pohon dari proses bisnis. Bahwa dari satu titik (tahap) koordinasi dimungkinkan untuk pergi pada cabang yang berbeda, tergantung pada pilihan pengguna (Koordinasi). Logis dan fleksibel. Tetapi setelah kami menyadari peluang ini dan meluncurkan sistem dalam produksi, tampaknya bagi kami bahwa sebenarnya kami tidak perlu memberi pengguna hak untuk memilih (kesempatan untuk berpikir). Baginya, semuanya harus terjadi pada level "Setuju", "Menolak". Kalau tidak, kita tidak akan bisa beralih dari prinsip memahami seluk-beluk interaksi karyawan di perusahaan. Dan untuk memenuhi kondisi ini, alur kerjanya harus
linier .
Tentu saja, ada beberapa "keingintahuan" juga.
Sebagai hasilnya, kami menemukan kompromi - arsitektur solusi dan implementasi alur kerja dibiarkan seperti pohon, tetapi penggunaan dari sudut pandang konfigurasi tetap pada tingkat "perjanjian". Dan mereka melakukannya dengan benar. Karena sekarang, ketika menganalisis tugas yang terkait dengan peluncuran jenis persetujuan baru, menjadi jelas bahwa pada beberapa tahap, untuk jenis aplikasi tertentu, kita perlu memberikan kesempatan kepada koordinator untuk memilih berbagai tindakan.
Sekarang sedikit tentang "pengetahuan" kita (setidaknya kita percaya akan hal itu). Untuk mencapai linearitas dan pada saat yang sama dapat menggunakan satu alur kerja untuk satu skema persetujuan (dengan skema, maksud saya entitas yang memerlukan keterlibatan dan urutan peran yang berbeda - kontrak, akun pembayaran, dll.), Kami telah memikirkan dan menerapkan mekanisme kondisi melewatkan tahap persetujuan selanjutnya. Dalam menciptakan kondisi, kita dapat menggunakan entitas apa pun dari kartu rekonsiliasi dan membandingkannya dengan "apa pun".
Misalnya, kami memiliki entitas berikut: Penggagas, Jumlah, Mata Uang, Mitra. Dan kita membutuhkan itu dengan jumlah kurang dari 100.000 rubel. koordinasi tidak melalui karyawan A, dalam pembayaran mata uang asing, itu harus dihubungkan dengan koordinasi B, dan jika penggagasnya adalah karyawan C, diperlukan koordinasi tambahan karyawan D. Selain itu, oleh karyawan yang kami maksud adalah individu dan kelompok tertentu. Untuk menerapkan poin-poin ini, kami menambahkan semua poin yang cocok "sejalan". I.e.: Inisiator-> A-> B-> D-> ...
Selanjutnya, kondisi untuk transisi "lulus" ke masing-masing titik koordinasi dibentuk. Misalnya, pada Inisiator Transisi-> A, kondisi "Jumlah <100.000" dikonfigurasikan, pada (Pemrakarsa) A-> B - Mata Uang = "Rubel", (Pemrakarsa, A, B) -> D - Pemrakarsa! = C.
Mengapa transisi ditunjukkan dalam tanda kurung? Karena kondisi dapat dipenuhi dalam kompleks dan "di bawah kap", jika kita membentuk suatu kondisi untuk transisi ke titik koordinasi, kita secara otomatis menghasilkan transisi sistem yang "memotong" titik ini (di sini arsitektur alur kerja seperti pohon membantu kita dan tidak ada "Kruk").Nah, sedikit lalat di salep. Kami belum sempat menerapkan mekanisme manajemen peringatan yang dapat dikonfigurasi. Meskipun awalnya diletakkan dalam arsitektur proyek. Seperti biasa, untuk mempercepat proses start-up, saya harus "sementara mengubah kode", dan saat ini kode tetap ini. Dan idenya adalah untuk menciptakan mekanisme yang mirip dengan jira, yang memungkinkan Anda untuk membuat skema pemberitahuan Anda sendiri, di mana Anda dapat mengatur pemicu (acara) dan mengaitkannya dengan grup atau karyawan tertentu dan dapat "melampirkan" ke semua jenis aplikasi.
Untuk mempercepat proses peluncuran, saya harus "sementara meng-hardcode".
Antarmuka
Beberapa antarmuka sistem kami, sehingga ada pemahaman tentang apa yang umumnya dibahas
Dasbor
Hal pertama yang dilihat pengguna sistem ketika dibuka (jika Anda tidak memperhitungkan proses otentikasi) adalah dasbor. Ini hanya menampilkan persetujuan aktif (tidak lengkap). Selain itu, aplikasi dibagi menjadi 2 segmen:
- Aplikasi yang memerlukan persetujuan oleh pengguna (Saya adalah pelaku)
- Aplikasi yang diprakarsai oleh pengguna (saya adalah pembuatnya)
Buat aplikasi baru
Antarmuka untuk membuat aplikasi baru dapat memiliki representasi (jumlah dan pengaturan elemen) sama sekali. Berikut adalah antarmuka sederhana yang menunjukkan kemampuan untuk memasukkan angka, pilih dari daftar, bendera (kotak centang), tanggal, lampiran.
Satu-satunya hal yang dapat Anda perhatikan adalah opsi "Buat lebih banyak". Ketika diaktifkan, setelah membuat aplikasi saat ini, kita tidak berada di dashboard atau di kartu aplikasi yang baru dibuat, tetapi formulir untuk membuat aplikasi baru dengan jenis yang sama seperti yang baru saja dibuat segera terbuka. Itu diimplementasikan atas permintaan karyawan kami, yang harus "bundel" membuat jenis aplikasi yang sama.
Tahap persetujuan
Antarmuka ini tidak jauh berbeda dari bentuk pembuatan aplikasi. Tetapi ia memiliki sejumlah fitur fungsional mendasar:
- Alih-alih tombol pembuatan, tombol muncul, klik yang mentransfer aplikasi ke salah satu dari proses bisnis. Dalam kasus degenerasi, seperti dijelaskan di atas, itu adalah "Tolak" dan "Setuju"
- Lampiran, komentar, dan entitas jurnal baru (riwayat tindakan) ditempatkan di tab terpisah
- Secara default, semua bidang aplikasi, kecuali untuk komentar, tidak dapat diedit. Pada saat yang sama, kami meletakkan fungsionalitas yang memungkinkan kami untuk memberikan pada setiap langkah koordinasi kemampuan untuk menyesuaikan hanya satu set bidang yang diberikan.
- Jika Anda adalah pemrakarsa aplikasi (Anda selalu dapat pergi ke kartu persetujuan) dan Anda memiliki opsi "Buat duplikat", ketika Anda mengkliknya, formulir pembuatan aplikasi terbuka, nilai-nilai bidang yang (kecuali untuk lampiran) menduplikasi nilai bidang aplikasi saat ini.
Jika Anda melihat lebih dekat, Anda akan melihat elemen oranye dengan nilai tambah di depan bidang pilihan Penghitung. Ini adalah fungsi mengelola direktori pribadi. Ketika Anda mengklik item ini, formulir untuk menambahkan item direktori terbuka.
Karena dalam kasus ini adalah Counterparty, maka elemen direktori di dalam kami berisi dua detail - Nama dan TIN. Setelah dibuat, pengguna dapat langsung memilih item ini dari daftar drop-down.
Cari
Dalam mencari aplikasi, sekumpulan properti ditampilkan di bagian atas untuk nilai yang harus Anda pilih. Set dapat dikonfigurasi oleh setiap pengguna untuk kebutuhan mereka dengan kemampuan untuk dengan cepat beralih di antara mereka.
Administrasi Proses Bisnis
Sebagai bagian dari mengelola proses bisnis, kami dapat membuat sejumlah titik jalan dan menunjukkan transisi. Akibatnya, grafik transisi terbentuk. Dan untuk setiap titik koordinasi kita dapat mengatur:
- Siapa yang cocok pada titik tertentu
- Izin untuk melakukan tindakan pada titik tertentu dalam rute
- Ketentuan untuk melewatkan titik ini (tahap persetujuan)
Cocok
Di tab "Koordinator", Anda dapat menambahkan grup, menambahkan pengguna yang mereka dapat melakukan proses persetujuan pada titik tertentu dalam proses bisnis.
Izin tindakan
Atas izin, Anda bisa tinggal lebih lama. Untuk membatasi tindakan koordinator terkait dengan mengubah nilai bidang (entitas) dalam aplikasi, mekanisme izin telah diperkenalkan. Saat ini, kami telah memasukkan 4 izin:
- Unduh lampiran
- Lihat lampiran
- Mengomentari
- Ubah nilai bidang aplikasi
Jika tiga yang pertama lebih atau kurang jelas, maka izin untuk mengubah bidang yang tersedia perlu dikomentari. Secara default, negosiator tidak dapat mengubah nilai bidang apa pun dalam aplikasi. Hanya mode tampilan yang tersedia. Jika perlu untuk memungkinkan mengubah bidang aplikasi individual pada titik persetujuan tertentu, opsi ini diaktifkan dan dimungkinkan untuk memilih dari daftar bidang aplikasi hanya yang nilai-nilainya dapat diubah ke yang cocok.
Meskipun agak dibuat-buat, tetapi misalnya, ini mungkin diperlukan jika Anda memiliki posisi terpisah "pembuktian kebenaran pengisian jumlah", kemudian beri dia kesempatan untuk mengubah hanya jumlah dalam aplikasi dan tidak lebih.
Kondisi Melewati
Melewati kondisi yang saya jelaskan di atas. Fungsionalitas diperlukan untuk membentuk proses bisnis linier tunggal untuk semua pengguna sistem, dan pada saat yang sama untuk melakukan pergerakan aplikasi di sepanjang rute dengan cara yang berbeda, tergantung pada kondisi yang diberikan dan tanpa intervensi pengguna.
Di layar, pengaturan disiapkan yang akan memungkinkan Anda untuk melewati titik rute ini jika penggagasnya dalam kelompok tertentu dan Mata Uang itu setara dengan rubel Rusia.
Alih-alih sebuah kesimpulan
Saat ini, perusahaan kami hanya meluncurkan satu jenis persetujuan. Tetapi dengan fleksibilitas penyesuaian, yang tertanam dalam sistem, kami memiliki alat yang memungkinkan Anda untuk mengkonfigurasi kartu aplikasi apa pun, di mana Anda dapat menentukan sejumlah bidang, representasi kartu aplikasi dan rute apa pun untuk koordinasi dengan berbagai kondisi.
Satu-satunya hal yang diperlukan adalah bekerja dengan analitik untuk mengumpulkan persyaratan dan kemudian mentransfernya ke sistem melalui antarmuka administrasi. Apa yang kita lakukan sekarang
Produk ini hidup, secara berkala kami melakukan perubahan atas permintaan karyawan kami, sebagai akibat dari mana kekuatan dan kegunaannya tumbuh, dan fungsi yang diimplementasikan memenuhi tugas yang dihadapi bisnis kami, dan kami selalu dapat mengatakan dengan yakin bahwa fungsionalitas yang diminta akan dilaksanakan jika jika memungkinkan.