Tentang apa artikel itu?

Ini adalah artikel umum tentang apa itu "otomatisasi anggaran", masalah apa yang ada di area ini, dan alat TI apa yang digunakan di dalamnya.



Jika Anda ingin memahami bagaimana BI, gudang data (DWH), sistem otomasi penganggaran (Cognos, Anaplan, 1C: Holding Management, Bit.Finance) saling berhubungan dan perbedaannya dari sistem informasi perusahaan lainnya, buka di sini.



Jika Anda seorang arsitek teknis yang belum pernah bekerja dengan bidang subjek perencanaan bisnis, artikel ini juga untuk Anda.





Saya segera memperingatkan Anda bahwa saya mencoba menulis artikel dalam bahasa yang sesederhana mungkin sehingga dapat dimengerti oleh semua orang.

Mengapa saya memutuskan untuk menulisnya?

Saat ini, praktis tidak ada deskripsi sistematis singkat tentang bidang ini, yang akan memberikan jawaban yang jelas atas pertanyaan:

1. ? ?
2. (PowerBI, Tableau, Qlik, Cognos, IBM Planning analytics, Anaplan, ., 1: ) ?
3. BI – ?

Perbedaan arsitektural antara akuntansi dan perencanaan adalah bahwa data akuntansi mengalir dari bawah ke atas. Untuk mendapatkan laporan berkualitas, Anda perlu mengatur pencatatan fakta sedetail mungkin. Kemudian informasi ringkasan apa pun (penting bagi manajer) dapat diperoleh dengan agregasi sederhana.



Oleh karena itu, dalam akuntansi, skema Document -> Table (Register) -> Report bekerja secara optimal (yang digunakan jauh sebelum otomatisasi, kembali pada akuntansi abad pertengahan).





Angka: 1. Skema akuntansi "Dokumen -> Daftar -> Laporan"





Rencana awalnya diperbesar. Oleh karena itu, akan lebih mudah untuk memasukkannya persis "dari atas" (yaitu, dalam bentuk yang sama dengan pembuatan laporan).



Oleh karena itu, ketika mencoba membangun otomatisasi penganggaran dengan analogi dengan akuntansi konvensional (Gbr. 3), perusahaan segera menghadapi tiga masalah utama.





Angka: 3



Masalah 1: Mengelola aturan . Sangat merepotkan dan menyita tenaga untuk mengatur aturan transformasi data (dari level akuntansi terendah hingga format penganggaran), yang tertulis di kode laporan.



Masalah 2: Kecepatan "mengumpulkan fakta" . Rencana ditampilkan dalam laporan dengan sangat cepat (karena sudah disimpan dalam bentuk yang diperbesar), dan data aktual dihitung dengan sangat lambat.



Masalah 3: Formulir entri rencana... Bentuk paling mudah untuk memasukkan rencana adalah laporan fakta rencana. Tetapi laporan dalam sistem informasi biasanya tidak mengizinkan pemasukan data.



Dua masalah pertama tidak hanya terkait dengan penganggaran, dan secara umum mewakili dasar dari seluruh area subjek data warehousing, integrasi data dan ETL.



Masalah ketiga adalah masalah perencanaan khusus. Yang sebenarnya merupakan salah satu masalah penting dari sistem ERP sebagai alat real-time (dirancang tidak hanya untuk akuntansi "anumerta" dari peristiwa yang telah terjadi, tetapi untuk perencanaan dan pengendalian operasional bisnis).

Masalah 1: mengelola aturan transformasi

Dalam gambar. 1-3, semua aturan untuk mentransformasikan data aktual (dari tingkat akuntansi terendah ke tingkat pelaporan atas) ditulis langsung di kode laporan.



Ini buruk:

• Aturan tidak dapat dikelola tanpa mengubah kode;
• Mereka hanya dapat digunakan dalam laporan ini.
  yang berarti:

  – , , ,
  
  – - ,
  
  

Kompleksitas aturan transformasi

Sangat penting untuk dipertimbangkan di sini bahwa aturan transformasi memang bisa sangat kompleks. Transformasi tidak selalu merupakan kumpulan data sederhana (dari hari ke bulan; dari departemen ke organisasi; dari gudang ke wilayah; dari lini produk ke artikel, dll.). Hal ini terutama terlihat dalam CIS, di mana akuntansi manajemen sering kali didasarkan pada akuntansi. Kemudian, dari berbagai kombinasi detail akuntansi yang berbeda, nilai akuntansi manajemen yang berbeda dapat ditentukan.





Anda dapat membayangkan seberapa besar masalah mempertahankan kode tersebut bagi pemrogram, jika ada beberapa ratus artikel seperti itu, artikel tersebut digunakan dalam lusinan laporan yang berbeda, dan aturan untuk menentukannya dalam akuntansi manajemen dapat disesuaikan setiap 3-4 bulan.

Solusi untuk masalah 1: pemetaan

Untuk mengatasi masalah ini, pemetaan - korespondensi antara bidang dengan tingkat yang berbeda dan / atau jenis akuntansi dan pelaporan - dapat diambil dari laporan, dibuat sebagai objek terpisah, dikonfigurasi dan disimpan secara terpisah, dan kemudian merujuk ke laporan tersebut jika perlu.





Angka: 4



Ini memiliki dua keuntungan sekaligus:

• Aturan lebih mudah untuk dikelola. Mereka dapat dibuat interaktif dan dapat disesuaikan tanpa kode, yang berarti bahwa pengguna biasa pun sering dapat melakukannya;
• Satu aturan dapat digunakan dalam berbagai laporan dan / atau algoritme lain

Pendekatan ini tidak memiliki kerugian yang berarti.



Tetapi mengembangkan alat untuk pemetaan yang mudah dari volume besar direktori tidaklah mudah.

Masalah 2: Kecepatan transformasi data aktual

Solusi untuk Masalah 2: Menyimpan Data yang Diubah

Agar tidak menghitung data laporan "dengan cepat", mereka sudah dapat disimpan dalam bentuk yang diperbesar dan diubah.



Untuk melakukan ini, selain tabel sumber (yang masih akan dibutuhkan di perusahaan), Anda perlu membuat tabel untuk menyimpan data aktual gabungan. Ini dapat berupa tabel terpisah, dan tabel umum untuk "rencana" dan "fakta" gabungan.



Tentu saja, tabel ini harus diisi terlebih dahulu: untuk ini kami akan melakukan prosedur transformasi yang sama yang dilakukan sebelumnya saat membuat laporan, tetapi sekarang kami akan memindahkannya ke proses latar belakang terpisah.





Angka: lima

DWH

Terkait dengan masalah ini adalah domain Data Warehouse (DWH).



Secara kasar, DWH adalah tempat (tabel atau, dalam praktiknya, satu set tabel terkait) untuk menyimpan data penghitungan menengah (agregat atau entah bagaimana diubah).



Apa kelebihannya:

• Kecepatan membaca data. Jika laporan "membaca" telah mengubah data dari tabel, mereka melakukannya dengan sangat cepat.
• Dapat diverifikasi. Ketika data disimpan sebelumnya di gudang, lebih mudah untuk memverifikasinya.

Minus:

• Ketepatan. Faktanya, minus ini agak teoritis (akurasi maksimum dipastikan dengan tepat ketika kami mengambil data dari sumber informasi yang paling utama).
  Saat latihan

  , ; , . , , , .
• Memuat memori. Karenanya, untuk menyimpan data agregat, kami membuang ruang ekstra pada hard drive. Juga, pada kenyataannya, lebih merupakan kerugian teoritis.
• Dekripsi. Jika kita menghubungkan laporan ke tabel gabungan (di mana datanya tidak dirinci sesuai dengan dokumen sumber), masalah muncul dengan kemungkinan dekripsinya (lihat perincian).

Proses ETL

ETL dapat disebut proses apapun dimana data diambil dari suatu tempat, dimodifikasi dan kemudian dimuat di suatu tempat. Ini adalah singkatan umum untuk Extract, Transform, Load.



Tetapi biasanya istilah ini digunakan secara tepat dalam kasus ketika data setelah transformasi ditulis di suatu tempat untuk penyimpanan.



Pendekatan ini memiliki keuntungan:

• Distribusi beban pada sistem. Proses transformasi berlangsung dari waktu ke waktu. Kami dapat mengisi tabel agregat secara bertahap (saat kami mengubah / menambahkan data dalam sistem akuntansi asli) atau sesuai jadwal. Misalnya, penghitungan rumit dapat ditunda dalam semalam atau jam non-bisnis lainnya saat server "gratis". Ini memungkinkan Anda untuk mengelola beban pada sistem.
• Transformasi satu kali. Setelah kami menulis informasi ringkasan ke dalam tabel gabungan, kami dapat mengaksesnya dari berbagai laporan. Oleh karena itu, transformasi yang sama tidak harus dilakukan berkali-kali.

Hanya ada satu minus:

• Kompleksitas pengendalian integritas data yang dimuat. Buat proses ETL yang tidak akan kehilangan data, yang cukup transparan dan terkendali - itu mungkin, tetapi ini membutuhkan tim yang berkualifikasi tinggi, keterlibatan pengguna, dan biaya tenaga kerja yang nyata.

Masalah 3: Formulir Entri Anggaran

Faktanya adalah bahwa dalam bentuk klasik, laporan dalam produk perangkat lunak merupakan sarana keluaran data. Tapi Anda tidak bisa memasukkan data ke dalamnya.





Tetapi untuk penganggaran skema klasik "Formulir masukan" (dokumen) -> tabel internal -> Formulir keluaran (laporan) "tidak sesuai.



Misalnya, pada suatu waktu kami mengembangkan laporan pengadaan bulanan (seperti pada Gbr. 2), tetapi sekarang kami mulai merencanakan, dan CFO ingin memasukkan anggaran pengadaan dalam bentuk yang sama.



Apa yang harus dilakukan? Anda dapat membuat formulir entri rencana yang terlihat sangat, sangat mirip dengan laporan ini (seperti yang ditunjukkan pada Gambar 3).

Solusi untuk Masalah 3: Formulir I / O Interaktif

Solusinya adalah juga jelas: bukannya biasa "dokumen" dan laporan", Anda harus membuat sebuah benda yang secara bersamaan akan dan untuk membaca dan memasukkan data.



Lebih baik lagi jika dalam objek ini juga dimungkinkan untuk melakukan penghitungan antara data yang dimasukkan dan / atau dibaca - yaitu, untuk bekerja seperti cara Excel memungkinkan Anda bekerja.



Dalam hal ini, rencana, setelah masuk, dapat "ditambahkan" ke gudang data yang sama di mana data sebenarnya berada (lihat gambar).





Angka: 6



Tetapi formulir seperti itu jauh lebih sulit untuk diimplementasikan daripada laporan atau dokumen biasa dalam sistem akuntansi.



Tingkat interaktivitas dapat berbeda: lebih mudah untuk mengimplementasikan formulir yang telah dikonfigurasi sebelumnya, lebih sulit - dinamis (di mana jumlah kolom / baris tidak diketahui sebelumnya, tetapi jenisnya telah ditentukan sebelumnya). Bahkan lebih sulit lagi untuk mengizinkan pengguna "merotasi" data, membuat formulir baru dan menyetel rumus kalkulasi sewenang-wenang, mengubah struktur laporan.

Solusi untuk masalah 4: kubus

Ada alat lain yang memecahkan masalah yang tidak disebutkan di atas.

Faktanya adalah bahwa dengan data dalam jumlah besar, dengan interaktivitas tinggi dan dengan rumus yang kompleks, tabel SQL relasional biasa, di mana biasanya untuk menyimpan data dari sistem ERP, tidak memberikan kecepatan maksimum pemrosesan data secara real time.



Untuk mengatasi masalah ini, Anda dapat menggunakan penyimpanan data bukan dalam bentuk tabel, tetapi langsung dalam bentuk kubus.





Benar, jika untuk tugas penganggaran segera mengatur penyimpanan dalam bentuk kubus adalah pilihan yang baik dan sesuai, maka untuk tugas bisnis lainnya model penyimpanan multidimensi mungkin tidak cocok, dan penyimpanan diatur menggunakan teknologi yang berbeda. Dalam hal ini, kubus dapat ditambahkan ke penyimpanan "utama", sebagai tautan lain dalam arsitektur.

JENIS PRODUK PERANGKAT LUNAK DALAM PENGANGGARAN

Sekarang mari kita pertimbangkan jenis teknologi informasi yang memecahkan masalah yang penting dalam penganggaran otomatis:

• Sistem data awal (sistem akuntansi, sistem ERP)
• Alat ETL
• Gudang data (kubus biasa dan OLAP)
• Sistem BI
• Sistem EPM
• Excel tentu saja

Setiap jenis sistem memiliki fungsi dasar teoritis (lihat tabel):







Namun pada kenyataannya, batasannya sedikit kabur, dan seringkali produk "tahu bagaimana" melakukan hal-hal terkait. Fungsi yang tumpang tindih secara kasar terlihat seperti ini:







Penting: Perlu dicatat bahwa fungsi tumpang tindih biasanya tidak 100%.



Artinya, biasanya alat yang menawarkan fungsi tambahan tidak menjalankannya sebaik alat khusus terpisah!

Peta jenis perangkat lunak dalam penganggaran

Secara umum, cakupan visual dari tugas yang berbeda untuk otomatisasi penganggaran oleh jenis sistem informasi yang berbeda dapat ditampilkan kira-kira seperti ini:





Gambar. 7



Sekarang mari kita lihat arsitektur penganggaran seperti apa yang ditawarkan beberapa produk perangkat lunak populer.

PENGANGGARAN DALAM SISTEM ERP

Konsep ERP berubah seiring waktu, dan kemampuan baru dimasukkan ke dalam sistem ERP.



Menurut pendapat saya, fungsionalitas ERP "klasik" mencakup sistem akuntansi; desainer laporan; fungsi pengendalian operasional rencana dan, tentu saja, kemampuan dasar masukan mereka.



Tidak termasuk: kemampuan untuk mengumpulkan data dari berbagai sumber; membangun kubus dan analitik interaktif



Ada alasan untuk percaya bahwa EPM (seperti BI) dipahami sebagai sesuatu yang melampaui ERP. Tapi sekarang batasannya kabur, dan fungsi EPM atau bahkan seluruh produk dapat dimasukkan sebagai modul dalam sistem ERP.

1C: SCP

UPP mengimplementasikan skema berikut, tetapi dalam satu basis.





Angka: 8. Arsitektur penganggaran di 1C: UPP



Keuntungan penganggaran di UPP:

• SCP sangat transparan dan mudah dimodifikasi. Sangat mudah untuk memverifikasi data di dalamnya dan cukup murah untuk mengembangkan fungsionalitas baru.

Pemetaan - di SCP pada tingkat rata-rata. Ini bukan plus atau minus. Menetapkan intensitas tenaga kerja rata-rata.



Kekurangan penganggaran di SCP:

• Kurangnya bentuk input-output yang interaktif. Pembuatan data apa pun dilakukan melalui dokumen (memasukkan rencana; memperoleh data aktual agregat; melakukan perhitungan), di mana tidak ada dan tidak dapat interaktivitas dan kemampuan untuk melihat gambaran besar.
• Kurangnya antarmuka ETL. Ada pemetaan, tetapi data aktual dimuat langsung dari formulir dokumen, yang merepotkan.
• Platform lama. Anda tidak dapat menggunakan teknologi Formulir Terkelola 1C, yang memberi pengguna kemungkinan modern untuk pemfilteran / pengurutan universal daftar dan laporan. Ini menurunkan kemampuan analitis pengguna.

Secara umum, dalam SCP, otomatisasi penganggaran paling jelas diterapkan sesuai dengan prinsip akuntansi biasa: pengguna tidak bekerja dari gambaran umum, tetapi dari dokumen utama (memasukkan rencana; memuat fakta; perkiraan), dan gambaran umum hanya dapat dilihat dalam laporan di mana tidak ada yang dapat dimasukkan.

1C: ERP

Sejauh yang saya ingat, awalnya ERP hanya menyediakan model pelaporan "online". Dan hari ini di banyak perusahaan skenario utama kerja persis seperti ini. Namun demikian, sekarang program memungkinkan penyimpanan perantara dari nilai yang dihitung.





Angka: 9. Arsitektur penganggaran di 1C: ERP



Keuntungan penganggaran di 1C: ERP:

• Bentuk input-output yang cukup fungsional

Kekurangan penganggaran di 1C: ERP:

• Kekakuan model. Pada prinsipnya, seperti pada kebanyakan sistem ERP, model anggaran tidak mentolerir perubahan yang sering terjadi dan agak pilih-pilih tentang pengaturan awal
• Pemetaan lemah. Untuk beberapa alasan, fungsionalitas pemetaan lebih buruk daripada di UPP
• Kekerasan produk. Tidak seperti SCP, sangat sulit dan mahal untuk mengerjakan ulang kerangka metodologi di sini. Anda perlu mempelajari yang sudah ada dengan baik, dan membangun penganggaran pada 1C: ERP, jika itu benar-benar sesuai dengan perusahaan
• Performa. Formulir interaktif cukup fungsional, tetapi perangkat teknis membuatnya sangat lambat pada data dalam jumlah besar

Juga di 1C: ERP tidak ada fungsi yang serius dalam hal pengaturan proses penganggaran organisasi (alur kerja) dan pekerjaan multi-pengguna. Misalnya, proses persetujuan disertakan dalam produk terpisah 1C: Alur Kerja, yang biasanya diterapkan di atas ERP.

1C: CA

Otomasi Terintegrasi adalah versi 1C: ERP yang dipreteli, jadi pengembangannya mengikuti jalur yang sama, dan tidak ada metodologi penganggaran sendiri.

MS Axapta / MS Dynamics AX

Hanya ada model "online" untuk melihat data anggaran yang sebenarnya - data tersebut dibaca langsung dari modul akuntansi mereka sendiri, sementara kemungkinan untuk transformasi yang serius tidak tersedia.





Angka: 10. Arsitektur penganggaran di MS Dynamics



Baik plus dan minus dari sistem adalah "penajaman" pada modul akuntansi Dynamics sendiri dan struktur siap pakai mereka.



Kelebihan:

• Integrasi dengan modul akuntansi. Menyiapkan memperoleh data aktual dari berbagai modul sistem ERP cukup sederhana.
• Integrasi. Ada banyak peluang untuk memuat rencana yang sudah jadi dari sistem eksternal. Dengan demikian, Microsoft dengan jelas mengikuti logika pemisahan EPM dari ERP, sebagai akibatnya sistem EPM "digantung" dengan sangat baik di Dynamics
• Alur Kerja. Model organisasi proses anggaran yang cukup fungsional dan transparan

Minus:

• ETL. Secara umum, produk tidak memberikan kemampuan transformasi data yang berarti
• Kekerasan produk. Metodologi yang sudah jadi, tetapi agak terbatas diatur di sini. Dan (seperti dalam kasus 1C: ERP) tidak hanya sulit untuk mendaur ulangnya, tetapi juga praktis tidak ada gunanya.

SAP S4 HANA

Produk SAP utama yang menggantikan sistem ERP SAP R / 3.



Untuk penganggaran, produk EPM terpisah sekarang digunakan, yang dalam versi desktop (SAP BPC) masih dapat dianggap sebagai sistem EPM terpisah "di atas" dari ERP, tetapi dalam versi cloud (SAP Analytics Cloud) akhirnya sudah diintegrasikan ke dalam sistem ERP (di SAP S4 HANA Cloud). Detail lebih lanjut tentang SAP BPC ada di bawah.



Penting untuk mengatakan hal lain tentang S / 4 HANA itu sendiri: SAP mentransfer semua pekerjaan sistem ERP dari database relasional ke database gabungan (campuran relasional, kolumnar, dan multidimensi). Basis data gabungan semacam itu adalah teknologi SAP HANA-nya sendiri (jangan disamakan dengan S / 4 HANA), yang, tergantung pada tindakan pengguna, berfungsi baik sebagai transaksional (sistem akuntansi) atau sebagai sistem analitik (kubus).



Jadi, SAP bergerak ke arsitektur yang berlawanan dengan apa yang sekarang dikenal dalam praktik "normal". Di dalamnya, database analitik tidak dibangun "di atas" penyimpanan (SAP BW), tetapi diimplementasikan "di bawah" sistem ERP. Dalam hal ini, gudang data (SAP BW), saat pengguna bekerja dengan datanya dari sistem EPM, mentransfer data untuk kalkulasi kembali ke basis data gabungan asli ini.



Faktanya, SAP mencapai efek yang sama dengan IN-Memory OLAP yang dipahami dengan cara yang berlawanan: dengan memaksimalkan penghitungan dari RAM.

Oracle Cloud ERP

Oracle juga mengambil jalan untuk menanamkan sistem EPM di dalam ERP.



Perusahaan secara aktif memindahkan produknya ke versi cloud (bahkan mungkin lebih aktif daripada yang dilakukan SAP). Oleh karena itu, untuk solusi EPM utamanya, Oracle Hyperion (yang juga akan kami bicarakan di bawah), perusahaan mempromosikan alternatif dalam bentuk Oracle EPM Cloud berbasis cloud, yang termasuk dalam Oracle Cloud ERP berbasis cloud.

BI-SISTEM

Sistem-BI (Business Intellegence) dalam bentuk "murni" adalah alat keluaran data. Artinya, BI adalah perancang laporan dan dasbor, yang biasanya juga berisi fungsi dasar untuk merestrukturisasi dan menganalisis data (misalnya, memungkinkan Anda untuk menggabungkan tabel, menemukan tren rata-rata, dll.).



Sistem BI populer:

• Power BI
• Tablo
• QlikView / QlikSense
• IBM Cognos TM1
• SAP BusinessObjects

Biasanya, BI terhubung ke penyimpanan data (relasional dan multidimensi) atau ke tabel SQL mentah. Dengan demikian, Anda dapat merujuk ke data sumber yang cukup mendetail (untuk menggabungkannya di BI). Namun, transformasi bersyarat yang kompleks (dengan kondisi "jika") bukanlah tentang fungsionalitas BI "klasik". Jika tugas Anda adalah membangun sistem visualisasi dashboard, ada baiknya Anda membangun transformasi sebelum menerapkan BI.

SISTEM EPM

EPM adalah singkatan dari Enterprise Performance Management. Juga, istilah Manajemen kinerja perusahaan (CPM) dan, yang lebih jarang, manajemen kinerja bisnis (BPM) ditemui.



Istilah yang cukup luas yang dapat menyiratkan fungsi terkait, tetapi paling sering sistem semacam itu dapat dianggap sebagai konstruktor bentuk interaktif "Rencana-fakta". Konsep EPM belum menjadi terkenal, tetapi solusi seperti IBM Planning analytics, Oracle Hyperion, Anaplan, yang kadang-kadang dipertimbangkan dalam konteks Business Intellegence, lebih tepat disebut sistem EPM.



Terkadang sistem EPM dibuat untuk tujuan yang lebih luas (misalnya, SAP EPM atau 1C: Holding Management), tetapi kami akan mempertimbangkannya secara tepat dalam hal sistem untuk otomatisasi penganggaran. Oleh karena itu, kami akan menyebut SAP Business Planning & Consolidation (SAP BPC) - sistem EPM, meskipun SAP sendiri menyebutnya sebagai produk SAP EPM yang lebih besar, yang mencakup SAP BPC.



Seperti yang kami katakan, BI tidak mengizinkan pemasukan data. EPM biasanya mencakup fungsi BI standar, dan sebagai tambahan menyediakan kemampuan untuk memasukkan dan menulis data.



Sistem EPM terkemuka:

• Oracle Hyperion
• IBM Planning Analytics
• Anaplan
• SAP BPC
• Bit.Finance
• 1C: Manajemen Holding

Mari kita mulai dengan yang kecil.

Bit.Finance

Bit.Finance didasarkan pada metodologi penganggaran UPP, namun, tidak seperti itu, pertama, ini didukung dan dikembangkan, dan kedua, diterapkan sebagai sistem EPM di atas ERP (dengan demikian, memungkinkan Anda untuk mengkonsolidasikan data aktual dari berbagai sumber eksternal).





Angka: 11. Arsitektur penganggaran di Bit.Finance



Keuntungan otomatisasi penganggaran di Bit.Finance:

• Pembuat formulir untuk memasukkan atau membaca data. Berbeda dengan UPP, bentuk dokumen akuntansi tidak diperbaiki di sini, tetapi dapat disesuaikan sehingga menjadi bentuk yang cukup nyaman.
• Antarmuka untuk mengelola perkiraan biaya. Anda dapat menghitung ulang model anggaran di sini secara terpusat, daripada membuat dokumen biaya secara manual.

Pemetaan lebih berkembang daripada di SCP.



Memperoleh data aktual bekerja dalam tiga cara:

• Melalui dokumen akuisisi bukti (seperti dalam SCP),
• Akuntansi paralel. Dalam opsi ini, dokumen akuntansi, saat disimpan, membuat entri simultan di register akuntansi dan register anggaran.
• Metode siaran. Dalam opsi ini, entri buku besar akuntansi diterjemahkan ke dalam buku besar anggaran.

Kekurangan otomatisasi penganggaran di Bit.Finance:

• Bekerja melalui bentuk dokumen. Terlepas dari kenyataan bahwa bentuk dokumen telah menjadi fleksibel (lihat plus pertama), dan secara umum, dalam aspek ini, banyak kemajuan telah dibuat dibandingkan dengan SCP, produk masih belum menyimpang dari model kerja berorientasi dokumen sejauh yang kami inginkan. Yang, seperti yang kami katakan, tidak nyaman untuk penganggaran.
• Kurangnya bentuk input-output yang interaktif. Tidak seperti 1C: ERP, tidak ada satu pun di sini.

Anaplan

Produk unggulan yang belakangan ini mendapatkan popularitas besar di pasar global. Hanya ditawarkan dalam versi cloud.



Tidak seperti solusi populer lainnya (termasuk Hyperion dan Planning Analytics), ia memiliki spesialisasi yang sedikit spesifik: ia bekerja paling baik sebagai layanan penetapan biaya yang memungkinkan Anda menghitung ulang model anggaran volumetrik dengan cepat dan otomatis dengan sejumlah besar ketergantungan.





Angka: 12. Arsitektur penganggaran Anaplan (skenario otomasi populer)



Kelebihan:

• Penetapan biaya. Produk ini berfokus pada penghitungan, dan menyimpan semua data dalam OLAP Dalam Memori, yang memungkinkan semua model dihitung ulang secara online
• Kerja tim (dalam persiapan data perencanaan)
• UX dan pemodelan bentuk bebas.
• ETL. Alat ETL yang dimiliki dan cukup nyaman
• Membutuhkan dukungan TI minimal. Terutama dalam hal pemodelan
• Biaya. Agak mahal untuk pasar Rusia, tetapi dibandingkan dengan pemimpin internasional (Oracle Hyperion yang sama), total biaya kepemilikan lebih rendah
• Kecepatan implementasi. Dibandingkan dengan Hyperion dan Planning Analytics, produk lebih mudah digunakan dan lebih mudah diterapkan

Minus:

• Pemformatan
• Kerja tim (dalam hal bekerja dengan acara: pemberitahuan, surat, dll.)
• Sintaks rumus kustom. Secara umum, menggunakan kode Anda sendiri selalu merupakan kerugian dari sudut pandang pengguna akhir.
• Hirarki. Dulu ada masalah dengan penggunaan hierarki direktori yang berbeda untuk model anggaran yang berbeda. Masalahnya tidak penting bagi banyak perusahaan, tetapi penting bagi beberapa perusahaan. Mungkin (saya harap begitu) Anaplan sudah memecahkan masalah ini sekarang.
• Ad-hoc . , : Anaplan , .

Baik plus dan minus Anaplan adalah spesialisasi yang relatif jelas dan fakta bahwa hal itu tidak mengganggu ekosistem TI perusahaan. Nilai tambahnya adalah bahwa produk tersebut telah dengan jelas mendefinisikan tujuan fungsionalnya, dan arah perkembangannya cukup dapat diprediksi. Ini adalah layanan untuk melakukan analisis Bagaimana-Jika, menghitung dan menyetujui rencana (anggaran), dan Anda perlu merencanakan arsitektur pelanggan berdasarkan ini. Sisi negatifnya adalah bahwa produk tidak dapat menggantikan gudang data perusahaan yang lengkap, tidak dapat menggantikan semua kemampuan BI, infrastruktur ETL perusahaan yang kompleks tidak dibangun di atasnya, dan memang seluruh sistem komputasi perusahaan. Semua ini tidak akan menjadi masalah jika produk tidak ditawarkan hanya dalam versi cloud.



Tidak seperti Oracle dan SAP (keduanya mengklaim sebagai ekosistem), Anaplan tidak menekankan kemampuan untuk "memindahkan" data dan alat dengan mudah antara cloud dan server perusahaan. Jadi, dalam kasusnya, kerugian produk cloud (dengan mempertimbangkan tarif yang bergantung pada jumlah data yang digunakan di server) tampak paling mencolok.



Karena tidak menggantikan penyimpanan perusahaan universal, dalam kasus tertentu ini dapat digunakan sebagai layanan kalkulasi yang "menambahkan" data rencana ke DWH perusahaan itu sendiri, dari mana data ditransfer ke sistem BI terpisah untuk membuat laporan cepat dan dasbor.





Angka: 13. Arsitektur penganggaran Anaplan (skenario otomatisasi alternatif)



Secara umum, penggunaan sistem EPM dan BI adalah praktik yang normal.

Oracle Hyperion

Muncul setidaknya dalam dua versi: Oracle Hyperion Planning dan Oracle Hyperion Financial Management.

Sekarang secara aktif digantikan oleh produk Oracle EPM Cloud yang baru.



Karena ekosistemisme, arsitektur dapat memiliki berbagai jenis, tetapi yang khas terlihat seperti ini.





Angka: 14. Arsitektur penganggaran di Hyperion (opsi yang memungkinkan)



Pada gambar, saya memberikan sistem BI sebagai contoh, karena database analitik Oracle Essbase adalah database yang sangat baik untuk analitik data besar dalam alat BI.



Oracle Data Integrator ditawarkan sebagai solusi ETL, yang bertindak sebagai mekanisme integrasi data universal dalam ekosistem Oracle.



Kelebihan otomatisasi penganggaran di Oracle Hyperion:

• Ekosistem. Dalam kasus Oracle, saya akan mencatatnya sebagai nilai tambah, karena Oracle adalah salah satu vendor database terbesar, dan integrasi untuk perusahaan yang mengerjakan Oracle DBMS (dan ada banyak perusahaan seperti itu) benar-benar memberikan keuntungan. Secara khusus, akan lebih mudah untuk mendistribusikan fungsionalitas antara cloud dan server. Selain itu, rekan kerja berbicara tentang keuntungan yang cukup serius dalam hal keamanan dalam arsitektur Oracle (saya bukan ahli dalam hal ini, jika ada di sini, mohon perbaiki).
• Ad-hoc ("pelaporan atas permintaan").

Kekurangan dari otomatisasi anggaran di Oracle Hyperion:

• Ekosistem. Saya juga mencatat sebagai minus, karena, menurut informasi yang tersedia, Hyperion dipilih terutama oleh perusahaan yang bekerja pada tumpukan teknologi Oracle, dan dari penggunaannya di lingkungan non-Oracle dalam jangka panjang, efek yang lebih kecil dimungkinkan.
• . , Anaplan.
• . , UX ( ).

IBM Planning Analytics

Terutama ditujukan untuk bisnis besar, tidak mudah diterapkan dan dikelola, tetapi sistem EPM yang sangat fungsional. Saat ini, IBM Planning analytics dibangun di atas teknologi TM1 (yang merupakan jantung dari Cognos).



Untuk proses ETL, IBM menyarankan agar menggunakan produk terpisah, IBM DataStage (sebelumnya digunakan oleh Cognos DataManager), Turbo Integrator, Cognos Integration Server, atau alat ETL eksternal.



Arsitektur tipikal sangat mirip dengan Hyperion.





Angka: 15. Arsitektur penganggaran dalam Planning Analytics (opsional)



Kekuatan IBM Planning Analytics:

• Peramalan.
• Bekerja dengan acara.
• Fleksibilitas. Produk tidak dapat disebut non-menuntut dalam hal pra-konfigurasi, tetapi mencoba untuk dapat beradaptasi dengan model yang berubah.
• Bukan ekosistem. Apa yang mengejutkan tentang bekerja dengan IBM adalah bahwa sejumlah besar bahan ajar yang diproduksi oleh perusahaan bertujuan untuk menjelaskan praktik terbaik untuk interaksi produk IBM dengan solusi lain (termasuk Oracle dan SAP), dan dalam berbagai masalah. Menurut pendapat subjektif saya, ada baiknya perusahaan dalam jangka panjang tetap mempertahankan tren untuk mengembangkan integrasi dengan sistem pihak ketiga (yang memungkinkan mendukung berbagai arsitektur yang telah berkembang di perusahaan), dan tidak menguranginya.
• Dukungan produk.

Minus

• Kompleksitas. Seperti Hyperion: Memerlukan pelatihan pengguna yang signifikan, bukan infrastruktur paling ringan.

SAP BPC

Secara umum, ciri khas SAP adalah ekosistem, kompleksitas arsitektur, dan infrastruktur solusi.



Seperti yang saya katakan, SAP telah mendukung dan mendukung opsi arsitektur yang berbeda pada waktu yang berbeda; menurut informasi terbaru, versi arsitektur andalan yang direkomendasikan oleh vendor saat ini terlihat seperti ini:





Gambar. 15. Arsitektur penganggaran di SAP Business Planning & Consoldation (contoh)



Keuntungan penganggaran berdasarkan SAP BPC:

• Integrasi data. Meskipun rumit, ini fungsional dan cepat, yang penting bagi perusahaan besar.
• Visualisasi.
• Alur Kerja.

Kekurangan penganggaran berdasarkan SAP BPC:

• UX . SAP, , .
• . , SAP . , : . , . , SAP SAP BW MS SQL Server, NetWeaver; BW/4 HANA NetWeaver; , EPM- SAP Analytics Cloud, .
• Harga. Dalam hal total biaya kepemilikan, ternyata ini adalah salah satu sistem EPM termahal di dunia, yang dipengaruhi oleh perubahan arsitektur.

ETL-TOOLS

Alat ETL yang terkenal digunakan untuk membangun proses ETL, di antaranya terdapat banyak produk dari vendor yang sama yang menghasilkan solusi BI / EPM:

• IBM DataStage
• Informatica PowerCenter
• Talend
• Apatar
• Layanan Data SAP
• Oracle Data Integrator
• Pabrik Data Microsoft Azure
• dan banyak lagi dr.

Rencananya artikel tersebut akan diperbarui secara bertahap, mungkin dengan tambahan informasi tentang produk baru dan prinsip-prinsip pengembangan produk perangkat lunak untuk penganggaran dari awal.