Tính mở trong phần mềm kế toán

Thảo luận trong 'Phần mềm kế toán' bắt đầu bởi phunv, 7 Tháng chín 2005.

4,721 lượt xem

  1. phunv

    phunv Thành viên sơ cấp

    Bài viết:
    1
    Đã được thích:
    0
    Nơi ở:
    Ha Noi
    Nói đến phần mềm đóng gói, ai cũng nói đến tính mở. Các công ty phần mềm kế toán đều quảng cáo sản phẩm mình có tính mở, nhưng đến đâu thì khó trả lời.
    Chúng tôi cũng có sản phẩm phần mềm kế toán, và chúng tôi cũng cho rằng sản phẩm của mình là rất mở, và quan điểm mở của chúng tôi lại nói nhiều đến khả năng customize các reports (có thể tham khảo tại đây).

    Theo tôi thì phần mềm kế toán VN rất yếu về khoản này, bạn nghĩ rằng tính mở phải thế nào và phần mềm nào ở VN có tính mở nhất.
     
    #1
  2. StonyHeartedMan

    StonyHeartedMan Thành viên sơ cấp

    Bài viết:
    306
    Đã được thích:
    2
    Nơi ở:
    Hà nội
    Ai định nghĩa hộ tớ thế nào là 1 hệ thống mở cái?

    Hoặc đơn giản hơn, tự nhiên khách hàng của tớ muốn thêm hẳn 1 chức năng mới (phải cắm thêm mấy modules khác trong và ngoài hệ thống), rồi muốn thay đổi nghiệp vụ nào đó có sẵn làm cho các khóa chính khóa phụ quan hệ trong DB phải làm lại hay thậm chí phải thêm cả mấy tables kiểu master-detail, 1 loạt các lookup tables chân gà chân vịt phải cắm thêm vào.... Rồi thông tin trên 1 thực thể (table) phải thêm mấy trường (fields) mới (mà toàn trường khóa link với các tables khác chứ ko phải trường độc lập mà mọi người hay thiết kế sẵn những trường reserved fields đâu).

    Bên cạnh đó, khách hàng lại muốn tra cứu tất cả các thông tin dưới mọi hình thức như liệt kê, tìm thông tin gốc (drill down), thông tin phân tích, thông tin thống kê nhiều chiều, tính toán các chỉ số trợ giúp quản lý mà phần mềm chưa có,.... nói chung khách hàng muốn "info at finger tip", cần thông tin nào thì có thông tin đó. Vậy, PM có "động", có "mở" đến mức có thể đáp ứng được TẤT CẢ những yêu cầu đó ko?

    Không những thế, có khách hàng từng muốn phải động về repports. Họ muốn report có thể chạy trên mọi nguồn dữ liệu từ Excel, txt, DB,... và có thể chạy ở mọi nơi thông qua web. Đã thế, họ còn muốn tự mình layout & format lại report, rồi họ lại muốn điều kiện để hiển thị dữ liệu lọc trên report phải động đến mức ... có bao nhiêu thông tin trên report thì có bấy nhiêu thông tin cần lọc chứ ko chỉ from date to date cùng với mấy đối tượng quản lý như khách hàng, nhà cung cấp, hàng hóa,... (gần như chức năng filter động nhưng ko phải cho grid mà cho report). Sau đó, khách hàng lại muốn kết xuất 1 phần (lại theo các điều kiện kết xuất) hoặc tất cả các thông tin trên report ra mọi nguồn dữ liệu để share cho các đối tượng khác hoặc để lưu trữ như Excel, PDF, TXT, DBF, HTML,.... Các phần mềm lớn như mySAP
    còn cung cấp ko chỉ 1 mà là 2 hay 3 cách (tools) từ basic đến advance để user có thể tự design report riêng cho mình.

    Mà tất cả những cái trên chỉ là cái mong muốn "động" trên quan điểm của khách hàng thôi. Còn động theo nghĩa thiết kế phần mềm thì lại có concepts hoàn toàn khác mà ko cần thiết phải nói lên ở đây.

    Đấy, quan điểm "động", "mở" của khách hàng (chứ ko phải của tớ đâu) thường là như thế đấy.

    Vậy quan điểm "động", "mở" đối với 1 PM của các bạn là gì? (Đã là quan điểm thì chỉ nói lên thôi chứ ko bình luận nhé)
     
    #2
  3. StonyHeartedMan

    StonyHeartedMan Thành viên sơ cấp

    Bài viết:
    306
    Đã được thích:
    2
    Nơi ở:
    Hà nội
    Tổng kết về cái động của Report:

    1. Động về đầu vào, về nguồn dữ liệu: Truy cập nguồn dữ liệu theo các giao thức truyền thông như HTTP,.... Kết nối trực tiếp vào databases (kiểu thiết kế 2 lớp), Hoặc trực tiếp từ các non rational database files (flat files) như txt, excel, cvs,...

    2. Động về điều kiện của report: Mấy cái form hiện ra trước khi hiện report ấy, tòan là những form được thiết kế sẵn với mấy cái textbox, combo, date box chứ có thấy động đậy gì đâu

    3. Động về format & layout,...: có thể cho phép user tạo báo cáo mới (có thể dựa trên các báo cáo mẫu), tự do sửa báo cáo (theo nhiều mức độ từ basic đến advance), có thể save lại thành báo cáo mới và có thể set nó là 1 báo cáo mẫu....

    4. Động về đầu ra - hiển thị: Có thể xem báo cáo ở mọi lúc, mọi nơi từ chương trình, web, hay trên Paml, mobile....

    5. Động về kết xuất dữ liệu: kết xuất ra tất cả các nguồn có thể và ko chỉ kết xuất toàn bộ thông tin trên report (kiểu WYSIWYG) mà còn có thể export những phần mà người sử dụng mong muốn (đỡ phải vào file excel hay txt... để edit lại)

    6. Quản lý các báo cáo: Cho phép hiển thị danh sách các báo cáo theo categories, thêm mới, sửa đổi, xóa, mở (preview, print), xem thuộc tính,... của báo cáo.

    Vậy, hệ thống báo cáo của các bạn đã "động" chưa?
     
    Last edited: 7 Tháng chín 2005
    #3
  4. hieppm

    hieppm Thành viên thân thiết

    Bài viết:
    72
    Đã được thích:
    1
    Nơi ở:
    Tp.HCM
    Động đến đâu là vừa phải???

    Động chứ không phải là "Làm theo yêu cầu" nếu làm theo yêu cầu khách hàng thì không gọi là chương trình động nữa rùi!!!

    Đa phần các phần mềm việt nam hiện nay đều là ... không động theo nhiều mặt.

    Động về đầu vào(thêm trường), layout kông khó nhưng phải trong phạm vi thiết kế database sẵn có. Còn ngoài phạm vi đã được thiết kế thì không còn gọi là động nữa mà là làm theo yêu cầu (tuỳ nhà cung cấp)

    Động về điều kiện Report ... không khó

    Động về kết xuất dữ liệu... không khó (có tools hết mà)

    Quản lý báo cáo ... không khó đó là công việc của lập trình và hệ thống khi thiết kế

    Cho khách hàng tự làm thêm và add báo cáo vào ... không khó nếu khách hàng sure là hiểu về ngôn ngữ lập trình của phần mềm.

    Còn nếu muốn động hơn nữa ??? Open source là giải pháp tốt nhất
     
    #4
  5. StonyHeartedMan

    StonyHeartedMan Thành viên sơ cấp

    Bài viết:
    306
    Đã được thích:
    2
    Nơi ở:
    Hà nội
    Yes. Nhưng nếu PM được thiết kế tốt, việc "động" như vậy là ko khó. Ở đây, ta ko bàn đến chuyện "xử lý thay đổi yêu cầu phần mềm" (cái đó thuộc về quản trị dự án mất rồi). Ta chỉ nói đến tính "động", tính "mở" mà thôi. Nhiều khi tính "động", tính "mở" đó là ko phải rành cho end users (nhưng end user được lợi vì nhà cung cấp PM triển khai nhanh kể cả khi có các yêu cầu phát sinh) mà là cho các implement partners. Bài toán lương là 1 ví dụ. Nếu ko estimates cho các yếu tố lương và dự tính sẵn (vì các yếu tố đó có cùng 1 dạng form nhập, chỉ khác nhau về thông tin mà thôi) thì đến với mỗi loại hình khách hàng ta sẽ phải sửa lại code phần mềm. Rất bất tiện và phần mềm ko thể "đóng gói" được. Nói vậy thôi, chỉ có các công ty có tiệm lực mới có khả năng này. Ai đã từng triển khai các hệ thống ERP lớn như Oracle eBusiness Suite, SAP mySAP,... thì chắc đã biết phần nào. Còn ta, tạm thời bỏ qua phần động kiểu này.

    Nhưng ko phải phần mềm nào cũng có (Chú ý: Ko phải là mấy cái form vẽ sẵn các trường ra đâu nhé (hầu hết là các chương trình hiện nay đều làm theo cách vẽ sẵn), điều kiện là do mình select từ report's property collection). Phải có 1 database để lưu trữ các report và các thuộc tính của report.

    Nhưng toàn là export ra toàn bộ report thôi. Cái này thì phải phụ thuộc vào tools như Crystal Report, Data Dynamics reports, Developer Express XtraReports, v.v...

    Hầu hết là ko đạt yêu cầu. Chỉ có list các report theo categories, run report (mà ko có create new report, edit report (report design engine), delete report, save report as template, v.v...). Chú ý: Ko phải user nào cũng có các quyền đó. Tuy nhiên mình ko nên xét đến chuyện trình độ của khách hàng vội mà hãy nói đến tính năng cần có của chức năng này.
    Nhiều khi ko phải làm chức năng này cho khách hàng. Chính nhà cung cấp, nhà triển khai độc lập thực hiện công việc này cho khách hàng. (SAP, Oracle,... viết ra những công cụ này để cho các công ty triển khai độc lập (partners) thực hiện customize cho khách hàng (nếu ko thì các bác parters ở VN méo mặt với các loại báo cáo tài chính cần có ở VN). Think global!
    No comment!
     
    Last edited: 8 Tháng chín 2005
    #5
  6. hieppm

    hieppm Thành viên thân thiết

    Bài viết:
    72
    Đã được thích:
    1
    Nơi ở:
    Tp.HCM
    To: StonyHeartedMan

    Phần mềm bên mình viết trên Oracle nên không khó để làm mấy chuyện đấy!
     
    #6
  7. squaremedia

    squaremedia Thành viên sơ cấp

    Bài viết:
    1
    Đã được thích:
    0
    Nơi ở:
    HCM
    Có một vấn đề là, phần mềm càng dẻo thì đòi hỏi người sử dụng càng phải động não mới có thể bóp nặn theo ý mình, phần mềm càng dễ sử dụng và đơn giản lại mắc chứng "cứng ngắc". Thế là trên thế giới này, bạn phục vụ tốt cho người này nhưng có thể người khác không hài lòng, thế nên mỗi phần mềm đều có phân khúc thị trường cho mình.
    Riêng tôi mở rộng một chút, trước khi xây dựng hệ thống trên MS SQL sever, Oracle được cho là tối tân, hãy nên cân nhắc vè vấn đề bản quyền, cả khách hàng của bạn tương lai đều phải có bản quyền mới được cài PM của bạn đấy. Nếu có ý định phát triển lâu dài thì rất nên suy tính vấn đề này.
     
    #7
  8. hai2hai

    hai2hai VNUNI Makes a difference

    Bài viết:
    2,012
    Đã được thích:
    128
    Nơi ở:
    Hà nội
    Hoàn toàn đồng ý! Hy vọng là những nhà cung cấp PM ở VN sẽ tư vấn cho khách hàng về chi phí. Trong đó có 1 chi phí liên quan đến mua lisences của phần mềm hệ thống (Ví dụ: Windows 2003 Sever, MS SQL 2005 Ent, Oralce xyz, v.v...). Còn nếu ko thì ít nhất cũng phải giải thích cho KH dần dần hiểu rằng có chi phí đó và nếu triển khai thì chỉ nên triển khai trên những nền Free như MSDE (max 15 concurrent users) thôi.
     
    #8

Chia sẻ trang này