Evolusi teknologi TI diizinkan untuk mengontrol aliran data yang sangat besar. Bisnis memiliki banyak solusi TI: CRM, ERP, BPM, sistem akuntansi atau setidaknya hanya Excel dan Word. Perusahaan juga berbeda. Beberapa perusahaan terdiri dari banyak cabang. Sebut saja "Piramida". Piramida memiliki masalah sinkronisasi data untuk tumpukan sistem TI. Vendor dan versi perangkat lunak berbeda untuk cabang secara signifikan. Selain itu manajemen perusahaan terus menerus memodifikasi persyaratan pelaporan yang menyebabkan serangan frustrasi di cabang-cabang. Ini adalah kisah tentang proyek yang kebetulan saya temui kekacauan yang perlu disistematisasikan dan diotomatisasi. Anggaran rendah dan tenggat waktu yang ketat membatasi penggunaan sebagian besar solusi industri yang ada tetapi membuka ruang untuk kreativitas.
Format tujuan umum
Perusahaan pelanggan menetapkan tugas untuk mengumpulkan data laporan dari semua cabang. Biarkan saya menjelaskan skala tantangan - ada puluhan sistem, termasuk keduanya: buatan sendiri dan monster seperti SAP.
Satu laporan dapat berisi data dari: akuntan, reparasi, manajer PR, EMERCOM, ahli meteorologi.
Sebelum proyek dimulai, sebagian besar data dikirim melalui email ke perusahaan kepala sebagai lampiran Word / Excel. Selanjutnya tampak seperti matahari terbenam yang dibuat secara manual: data diproses secara manual oleh staf yang dipelajari secara khusus dan dimasukkan ke dalam beberapa sistem. Pada akhirnya ada lusinan laporan yang menjadi dasar keputusan manajemen.
Pilihan pendekatan diminta oleh format file yang digunakan - xlsx / docx. Bahkan perangkat lunak lawas mendukung pengunggahan data ke format ini. Setidaknya copy-paste bisa menjadi stand terakhir untuk cabang.
Jadi rencana pendapat kami adalah:
- Jelaskan struktur dan jadwal setiap laporan.
- Berikan cabang dengan peraturan laporan. Cabang harus menggunakan perangkat lunak yang ada untuk mengirim laporan melalui email. Jika tidak ada perangkat lunak - kirim laporan secara manual seperti sebelumnya.
- Kembangkan sistem, bahwa:
- mengambil dokumen yang benar dari kotak masuk email;
- mengekstrak data dari dokumen;
- menulis data yang diekstraksi ke DB, dan menghukum pelanggar peraturan.
Implementasi
Masalah non-pembangunan
Selama tahap pengumpulan persyaratan ternyata tidak ada deskripsi struktur laporan. Tidak ada sama sekali. Struktur laporan disimpan di kepala beberapa karyawan dan ditransfer secara verbal sebagai cerita rakyat. Masalah itu diselesaikan dengan beberapa upaya, tetapi tantangan sebenarnya dimulai kemudian pada tahap pengaturan pertukaran data.
Masalah pertama
Dalam beberapa hari setelah rilis versi beta kami mengungkapkan kesenjangan antara struktur dokumen dan model dokumen. Kualitas data buruk: laporan memiliki divergensi dalam jumlah, kolom tercampur, atau memiliki penamaan yang salah. Masalah-masalah ini terutama terjadi di cabang tempat data dikumpulkan dan dikirim secara manual.
Solusi - implementasi verifikasi tiga langkah:
- Menyediakan cabang dengan sampel xlsx yang memiliki struktur diperbaiki oleh alat Excel. Hanya sel yang tersedia dalam sampel ini yang merupakan input data. Beberapa sel mengambil verifikasi tambahan: jenis, konvergensi jumlah, dll.
- Verifikasi data saat mengekstraksi. Misalnya membandingkan tanggal dan tanggal saat ini dalam paragraf Word, verifikasi data aritmatika untuk dokumen Excel (jika tidak mungkin diatur oleh alat xlsx).
- Analisis data mendalam setelah ekstraksi. Misalnya deteksi penyimpangan yang signifikan oleh indikator utama dibandingkan dengan periode sebelumnya.
Masalah kedua
Pelanggaran sistematis terhadap jadwal transfer data atau upaya sabotase yang tidak bermoral: "Kami tidak pernah mengirim data apa pun kepada siapa pun, dan di sini Anda bersama ini ...", "Saya mengirim semuanya! Tepat waktu! Mungkin Anda tidak mendapatkannya karena latensi buruk. "
Umpan balik menjadi solusi. Perangkat lunak secara otomatis memberi tahu orang yang bertanggung jawab di cabang jika terjadi pelanggaran jadwal.
Beberapa waktu kemudian modul umpan balik dihubungkan dengan modul pemeriksaan kualitas data dan modul pembuatan laporan akhir. Cabang cara ini segera menerima ringkasan data sendiri dan perbandingan dengan "cabang tetangga". Jadi jelas bagi cabang, mengapa ditegur.
Modul yang dikembangkan
Laporkan alat konfigurasi template, yang menjelaskan:
- atribut untuk mengidentifikasi laporan;
- peraturan transmisi;
- algoritma ekstraksi data;
- atribut lain seperti jalur ke kode yang memvalidasi dan menyimpan data.
Aplikasi email yang memindahkan lampiran ke penyimpanan terisolasi (kotak pasir) dan menyimpan informasi terkait surat;
Pengurai lampiran yang mengidentifikasi laporan dan mengekstrak data.
Alat konfigurasi
Secara historis, surat dengan laporan mengirim ke alamat email umum serta banyak surat penting atau tidak penting lainnya. Itu sebabnya kami membutuhkan atribut untuk mengidentifikasi jenis lampiran laporan. Penggunaan nama dokumen atau teks tertentu dalam badan email tidak dapat diandalkan dan tidak nyaman bagi pengirim. Itu sebabnya kami memutuskan bahwa identifikasi laporan hanya akan ditentukan oleh konten.
Brainstorming menghasilkan banyak atribut untuk mengidentifikasi jenis laporan berdasarkan konten: warna teks sel, font, dll. Tetapi cara yang paling tepat adalah kehadiran substring dalam sel tertentu - "slot", atau dalam array sel untuk Excel. Untuk Word kami menggunakan paragraf atau judul.
Kami menambahkan logika perbandingan sederhana untuk "slot": "sama", "tidak sama", "lebih", "kurang", dan sebagainya. Contoh untuk laporan Excel: dalam rentang A2-E4, teks sel harus sama dengan "Laporan pemuatan peralatan harian".
Cara yang sama kami mengonfigurasi area pencarian untuk awal dan akhir data.
Di bawah ini adalah contoh kondisi pencarian untuk data yang berakhir: "2 baris kosong berturut-turut".
Beberapa pengaturan lain: daftar pengirim yang diizinkan, jenis dokumen (Excel / Word), jalur untuk ekspor data.
Outputnya adalah struktur JSON (templat) yang menggambarkan laporan.
Aplikasi email
Aplikasi ini adalah pembaca kotak masuk email yang menempatkan semua lampiran ke kotak pasir, menyimpan atribut email, mengatur lampiran ke antrian parsing.
Kami menghadapi 2 masalah keamanan:
- bagaimana jika nama cabang dalam laporan secara tidak sengaja (atau tidak) diganti dengan nama cabang lain?
- bagaimana jika laporan dikirim oleh penyusup?
Masalah pertama diselesaikan dengan memeriksa alamat email pengirim cabang dan nama cabang yang ditentukan dalam badan laporan.
Masalah kedua diselesaikan dengan menggunakan
SPF .
Parser lampiran
Hampir semua perpustakaan parsing Word dan Excel hanya mendukung versi / ekstensi tertentu. Itu sebabnya kami memutuskan untuk menggunakan konversi "Libre Office" untuk membawa file ke format tunggal. Misalnya input: odt, doc, docx (2007, 2010, 2013) ... convert to docx (2016).
Setelah konversi:
- kami memfilter berbagai templat laporan berdasarkan atribut dasar seperti apakah itu Word atau Excel, pengirim milik daftar yang diizinkan;
- mengancam laporan dengan templat yang tersisa;
- jika laporan cocok dengan templat - ekstrak data dan transfer ke repositori.
Lanjutkan
Kami berhasil!
Setelah dua bulan bekerja keras, kantor pusat mulai menerima data untuk laporan dari semua cabang secara teratur.
Kualitas dan kelengkapan data menjadi lebih baik dari sebelumnya. Perangkat lunak yang diimplementasikan telah merilis sumber daya manusia yang membayar kembali biaya proyek pada akhir tahun.
Bagi kami sendiri, kami belajar bahwa proses integrasi tidak selalu menyakitkan dan telah mengidentifikasi aspek-aspek utama kesuksesan:
- kami tidak masuk ke sistem di dalam cabang;
- kami meresmikan dan menyetujui struktur pelaporan terpadu dan jadwal transfer;
- kami membuat sampel keluaran untuk setiap jenis laporan dengan verifikasi bawaan;
- kami menggunakan cara paling umum untuk mengirimkan data - email.
Sebagai kata terakhir, pendekatan ini memiliki dua kelemahan utama:
- kecepatan pengiriman data rendah;
- ukuran paket data tidak boleh lebih besar, dari rata-rata lampiran email.