Mua hàng:0983715689 Diễn đàn   Đặt câu hỏi
Hỗ trợ sử dụng Tư vấn mua hàng
Call 04.5148550
Call 04.5148550
Call 04.5148550
Call 04.5148550
Call 04.5148550
Phản hồi, ý kiến góp ý của bạn với 1VS Phản hồi - góp ý
Hotline:(0988-721-127)
(04) 3514-85-50
(04) 3514-85-51
(04) 3514-84-30
Ý kiến nhận xét

Chị Trần Thị Lâm - Kế toán - Công ty cổ phần Tập đoàn Thái An

"...Lúc bắt đầu sử dụng, bên mình cũng gặp nhiều khó khăn vì chưa quen với phần mềm mới. Tuy nhiên khi đã hiểu các nguyên tắc làm việc của 1C thì mình nhận thấy đây là công cụ đắc lực cho người sử dụng trong việc việc kiểm tra, kiểm soát và đưa ra báo cáo giúp đơn giản hóa công việc của mình...".

Anh Trần Quang Thiện - Chủ Nhà sách cô Hường

"... Mình đặc biệt ưa dùng tính năng tổ chức danh mục phân cấp không giới hạn của phần mềm: hàng hóa và khách hàng được ghi nhận theo từng nhóm nhỏ. Điều này không chỉ hỗ đắc lực cho thu ngân bán hàng chính xác và nhanh chóng mà còn rất tiện dụng khi thiết lập và quản lý các chương trình khuyến mại, chiết khấu cho từng nhóm khách hàng theo một hoặc nhiều nhóm sản phẩm...".

1C:Quản lý tổng thể (ARM)


Đăng ký nhận bài viết

  1. Bạn đang dùng giải pháp 1C nào?
    1. 1C:KẾ TOÁN 8
      1181 (98.83%)
    2. 1C:Bán lẻ 8
      305 (25.52%)
    3. 1C:Quản lý thương mại
      140 (11.72%)
    4. 1C:Quản lý tổng thể (ARM)
      93 (7.78%)
    5. 1C:Quản lý văn bản (ECM)
      72 (6.03%)
    6. 1C:Hóa đơn
      67 (5.61%)
    7. 1C:Hiệu thuốc
      54 (4.52%)
    8. 1C:Cửa hàng điện máy
      52 (4.35%)
    9. 1C:Nhà hàng
      47 (3.93%)

Thông tin công nghệ, giải pháp

Với tốc độ nào thì cần và có thể phát triển giải pháp ứng dụng?
21/06/2013 - Số lần đọc: 5158

Giải pháp ứng dụng luôn phát triển. Cần phải phát triển. Điều này rất rõ ràng. Nhưng có thể và cần phải phát triển nhanh ở mức độ nào?

Tất nhiên, nói chung thì đây là một câu hỏi vĩnh cửu. Gần như mang tính triết học. Không thể có câu trả lời đúng. Chính xác hơn là luôn cần trả lời liên tục. Tiếc rằng, không thể một lần đưa ra một quyết định rồi sau này tuân theo mãi mãi.

Trong tiêu đề của bài viết này có bao gồm 2 mặt của một vấn đề: tốc độ được phép và tốc độ cần thiết để phát triển.

Mặt thứ nhất của vấn đề là tốc độ được phép để phát triển giải pháp ứng dụng. Nếu như đứng dưới cách nhìn về khả năng của nhà cung cấp thì nó bị hạn chế bởi khả năng của người sử dụng khi chuyển lên phiên bản mới mà không bị thiệt hại. Thiệt hại ở đây được hiểu là trong đó bao gồm những khó khăn về tâm lý do không quen thuộc, vì việc bắt buộc phải nắm bắt các tính năng mới, vì việc thay đổi phản xạ làm việc trong công việc hiện tại…

Tất nhiên, những thiệt hại này có thể được bù đắp một phần bằng các tài liệu phương pháp khác nhau, hoặc bằng cách chuyển đổi dần dần sang phiên bản mới (bằng cách có thể nhất)… Tuy nhiên, tốt hơn hết là những thiệt hại này được bù đắp bằng những ưu việt rõ ràng và hiển nhiên dành cho người sử dụng. Nhưng tiếc rằng, không phải bao giờ cũng đạt được như vậy.

Thông thường, những cái mới về tính thuận tiện và hiệu quả không được nhìn nhận ngay, mà chỉ sau một khoảng thời gian nào đó.

Đôi khi, những cái mới được tiếp nhận một cách tích cực chỉ bởi những người sử dụng mới. Bởi vì nó dễ hiểu hơn. Mức độ dễ hiểu cũng chính là thứ cần thiết dành cho người sử dụng mới. Bởi vì những người sử dụng đã làm việc lâu rồi thì tất cả đều đã được nghiên cứu.

Nhưng những ca "trầm trọng" nhất là khi mà cái mới không đem đến cho người sử dụng những cảm giác lợi ích rõ ràng ngay lập tức. Khi mà cái mới cần để giải quyết một loạt các bài toán chiến lược mà rất quan trọng đối với nhà cung cấp, và cũng chính là đối với người sử dụng cuối. Nhưng những người sử dụng rất khó có thể cảm nhận điều này "tại đây và ngay lập tức". Điều này chỉ xuất hiện dần dần. Nhưng chính vì nguyên nhân này mà người sử dụng sẽ rất khó nhận thấy mối liên hệ trực tiếp các thay đổi và những khó khăn trong việc chuyển đổi hiện thời với những lợi ích nhận được sau này.

Mặt thứ hai của vấn đề là tốc độ cần thiết để phát triển giải pháp ứng dụng. Nó được dựa trên cơ sở của hàng chục xu hướng và khả năng khác nhau. Đó là xu hướng phát triển xã hội, xu hướng công nghệ, và cuối cùng là xu hướng "luôn hoàn thiện". Thường thì các xu hướng riêng biệt và chiều hướng phát triển thường luôn xung đột lẫn nhau, nhưng điều này hoàn toàn bình thường.

Có một xu hướng quan trọng, đó là các thay đổi trong cuộc sống đã trở nên nhanh hơn. Một phần tối thiểu trong đó đã ảnh hưởng đến công nghệ thông tin.

Một phương diện khác, có lẽ, đó là cách tiếp cận và xu hướng trong CNTT sẽ trở nên ít giáo điều. CNTT ngày càng không còn đi theo kiểu "diễu hành" nữa. Trước đây, thông thường, có thể thấy rằng, "phần mềm hiện đại cần phải có giao diện thế này", "kiến trúc hiện đại cần phải như thế kia". Còn bây giờ, trong phần lớn các phương diện đều tồn tại song song nhiều cách tiếp cận, cạnh tranh lẫn nhau, nhưng đồng thời lại bổ sung cho nhau.

Trong những điều kiện như vậy, cần phải hướng đến không phải là nhóm lớn người sử dụng mà là đến đội ngũ tiên phong, những người luôn tích cực "tìm kiếm" những trải nghiệm mới: thiết bị, kịch bản, cách tiếp cận với công việc của hệ thống… Bởi vì, những khả năng mới thì không những chỉ cần được làm ra, mà còn cần phải được đưa vào áp dụng thực tế. Và như vậy,  cần phải kịp làm ra trước khi trở thành cấp thiết. Bởi vì, khi nhu cầu về cái mới đã trở nên cấp thiết không chỉ cho những người tiên phong, mà cho cả phần lớn người sử dụng thì việc xây dựng và phát hành giải pháp mới đã trở nên quá muộn.

Tất nhiên, những gì đã nói ở trên đều mang tính chung chung. Còn trên thực tế, chúng tôi cần đưa ra những quyết định cụ thể. Khi nào và làm thế nào để đưa những thay đổi lớn vào nền tảng công nghệ 1C:DOANH NGHIỆP? Khi nào cần phát hành phiên bản mới của giải pháp ứng dụng và với những ý tưởng sáng tạo nào? Bằng cách nào có thể cho phép chuyển đổi? Có thể thay đổi giao diện ở mức độ thế nào?

Tất nhiên, những vấn đề này đều được đặt ra với tất cả những công ty phát triển phần mềm mà có ít nhất khoảng 1000 khách hàng. Hơn nữa, nó đã trở nên cấp thiết trong trường hợp của chúng tôi, khi nói đến hàng triệu người sử dụng.

Trong tình huống khó xử này – phát triển hay chờ đợi – có một phương diện kỹ thuật nữa, đó là vấn đề về tính ổn định và chất lượng.

Nếu như không cần thay đổi gì hoặc thay đổi không nhiều thì việc đảm bảo tính ổn định và chất lượng không phải là việc khó. Còn nếu như phát triển một hệ thống thì mức độ phát triển càng nhanh bao nhiêu thì tính ổn định và chất lượng càng khó đảm bảo bấy nhiêu.

Nhưng có một phương diện hoàn toàn ngược lại. Thông thường thì nếu không đưa vào phần mềm những thay đổi lớn thì không thể có được những cải tiến về chất lượng.

Ví dụ, ở phiên bản 8, chúng tôi đã tiến hành tái cấu trúc toàn phần một số cơ chế mấu chốt trong hệ thống. Thực chất thì chúng tôi viết lại từ đầu. Chúng tôi hiểu rằng, nếu không có những biện pháp quyết liệt mà chỉ sửa một số lỗi và chỉ có các thay đổi nhỏ thì chúng tôi không thể đảm bảo chất lượng cần thiết cũng như phát triển hệ thống.

Tất nhiên, công việc thực tế còn phức tạp hơn, khi để nâng chất lượng ở mức độ mới thì cần phải tái tạo không chỉ các kiến trúc bên trong mà còn cả mô hình bên ngoài cho các chuyên gia và cho người sử dụng cuối. Điều này cũng gặp phải khi triển nền tảng  công nghệ 1C:DOANH NGHIỆP 8, và cả khi phát triển giải pháp ứng dụng.

Hiển nhiên, ngoài việc nâng cao chất lượng bằng cách hoàn thiện kiến trúc, khi phát triển nhanh hệ thống thì cần phải có nhiều nỗ lực cho những quy trình thường xuyên: gỡ rối, kiểm thử, sửa lỗi. Chúng tôi hiểu rằng, những quy trình này luôn đòi hỏi chúng tôi phải hoàn thiện. Ít nhất là bởi vì các yêu cầu về chất lượng, nói một cách khách quan, thường xuyên được nâng cao.

Khi thảo luận với người sử dụng và đối tác về các vấn đề này, chúng tôi nhận được những đánh giá và lời khuyên hoàn toàn trái ngược nhau. Ở đây, nói chung là không thể khác. Từ những câu hỏi "Các anh phát triển nhanh như thế để làm gì?" đến "Khi nào thì các anh mới phát triển thêm tính năng...?". Và chúng tôi hiểu rằng, đây không phải là những ý kiến khác nhau của những người khác nhau. Đơn giản là tại mỗi thời điểm, mỗi người đều "lo lắng" đến mặt này hay mặt khác của vấn đề.

Còn có một hiện tượng nữa mà tiếc rằng, rất khó kiểm chứng. Một số phương diện trong công nghệ và giải pháp ứng dụng có thể không cần cho lập trình viên hoặc một người sử dụng cụ thể nào đó, nhưng lại có giá trị đối với họ bởi vì trong hệ thống đã có khả năng đó.

Ví dụ, khả năng làm việc từ xa hoặc làm việc qua Web-browser (trình duyệt Web), rất nhiều người sử dụng hoặc thậm chí nhiều chuyên gia không coi đây là một yếu tố thực sự cần thiết. Cho đến khi mà nhu cầu này còn chưa phát sinh ở chính chỗ họ. Nhưng rất nhiều chuyên gia hiểu rằng, việc có sẵn những khả năng như vậy sẽ là một tấm khiên bảo vệ tốt nhất trong những tình huống, khi mà việc có sẵn tính năng này lại là yếu tố cần thiết để đảm bảo sự thành công của dự án. Thật là tốt, khi mà "người sử dụng cần có, còn chúng ta đã có sẵn rồi".

Còn một điểm quan trọng nữa, đó là chuyển từ các phiên bản trước một cách "êm ái". Những người làm việc nhiều với nền tảng công nghệ 1C:DOANH NGHIỆP 8 có thể thấy rõ điều này. Trong khoảng thời gian cuối gần đây, chúng tôi chú trọng nhiều hơn vào tính "êm ái" khi chuyển phiên bản. Chúng tôi hiểu rằng, giá trị tổng thể (giá trị, mức độ quan trọng)  của các ứng dụng trên nền tảng 1C:DOANH NGHIỆP 8 là rất lớn.

Ban đầu, chúng tôi làm ra cơ chế đơn thuần là "chuyển đổi". Sau đó, chúng tôi đưa thêm vào thuật ngữ "chế độ tương thích", trong đó nền tảng công nghệ mới sẽ "mô phỏng" công việc của nền tảng cũ trong tất cả các phương diện. Đôi khi, việc mô phỏng này được thực hiện một cách "máy móc", thậm chí tái tạo lại cả những hành vi "có lỗi" trong phiên bản cũ, để sao cho không làm thay đổi hành vi của giải pháp ứng dụng.

Sau đó, chúng tôi thực thi những thay đổi về cấu trúc dữ liệu khi thay đổi chế độ tương thích. Nghĩa là phiên bản mới biết "nhào bột ngược trở lại": phục hồi cấu trúc phiên bản cũ khi cần phải chuyển ngược về phiên bản trước.

Còn trong phiên bản 8.3.3, ngoài chế độ tương thích trước đây, chúng tôi làm thêm 2 chế độ tương thích riêng biệt. Chế độ tương thích về giao diện (có thể sử dụng giao diện cũ hoặc giao diện mới "Taxi") và chế độ sử dụng biểu mẫu "modal" (có thể làm việc như trước đây hoặc tắt bỏ việc sử dụng tính "modal" – chế độ được khuyến cáo). Như vậy, bây giờ người lập trình có thể chuyển ứng dụng sang phiên bản mới dần dần và có thể quay ngược trở lại phiên bản trước khi cần thiết.

Hiển nhiên, việc hỗ trợ khả năng tương thích ở mức độ này không phải là điều đơn giản. Đây là sự nỗ lực vượt bậc trong việc lập trình và kiểm thử hệ thống. Nhưng chúng tôi cho rằng, nó thực sự cần thiết.

Có một cách làm nữa được áp dụng mà trong lúc thảo luận, chúng tôi so sánh giống như việc di dời một chiếc tủ. Bạn đã bao giờ một mình thử di chuyển một chiếc tủ lớn từ góc nhà này sang góc khác hay chưa? Nếu đã từng làm thì tất nhiên có thể biết một số cách làm ("phương pháp").

Ví dụ, có thể đặt lên một tấm bìa và kéo đi. Có thể mua bàn trượt chuyên dụng để kê vào rìa tủ. Còn có thể di dời chiếc tủ theo từng phần. Nâng một đầu tủ, xoay một góc nhỏ quanh chân tủ ở góc đối diện, sau đó làm như vậy từ góc khác và cứ thế.

Có thể áp dụng phương pháp như vậy khi phát triển các giải pháp ứng dụng. Trong trường hợp này, chúng ta nói về nền tảng công nghệ và về giải pháp ứng dụng. Ở một bước nào đó, chỉ thay đổi một phương diện nhưng không động chạm đến các phương diện khác. Điều này cho phép không "đổ lên đầu" người sử dụng và lập trình viên các thay đổi trên tất cả các mặt trận. Và như vậy, cho phép đứng vững trên một biên mong manh về mức độ thay đổi được phép.

Còn nữa, sự cần thiết nữa cần duy trì tốc độ phát triển là tiền đề cho một quá trình phức tạp khi lập kế hoạch và triển khai. Ví dụ, việc phát triển nền tảng công nghệ của chúng tôi hiện nay được thực hiện ở 5 tầm kế hoạch.

Trong phiên bản phát hành trong vòng 2-4 tuần, và khi cần thiết, trong 1-2 ngày, chúng tôi đưa vào đó những bản vá lỗi nghiêm trọng. Trong phiên bản phát hành trong vòng 3-4 tháng, chúng tôi đưa vào các cải thiện nhỏ về tính năng và sửa chữa phần lớn các lỗi. Trong tầm thứ 3, chúng tôi đưa vào các thay đổi lớn về tính năng. Và còn có 2 tầm kế hoạch nữa. Khi tầm kế hoạch càng lớn thì quy mô thay đổi càng nhiều.

Nếu như trong phần kết luận mà cần trả lời câu hỏi "Làm thế nào tốt hơn?" thì chúng tôi cho rằng, phát triển cần phải nhanh, nhưng cần phải đi kèm theo tất cả các biện pháp có thể để đảm tính kế thừa quá trình này dành cho người sử dụng.

Có nhiều thứ sẽ cần cho ngày mai, nhưng cần chuẩn bị từ ngày hôm qua. Chúng tôi thấy, ngoài những gì mà chúng tôi đang tích cực phát triển, còn có nhiều phương diện mà cần phát triển nhanh hơn. Và trong bất kỳ trường hợp nào, chúng tôi cũng cần lựa chọn xem phương diện nào của hệ thống trong giai đoạn hiện tại được ưu tiên hơn. 

Nhưng việc lựa chọn các ưu tiên lại là một chủ đề của một câu chuyện khác.

Tác giả: Nuraliev Sergei - Phụ trách khối giải pháp kinh tế, hãng 1C
Nguyên bản tiếng Nga: http://www.v8.1c.ru/o7/201306sp/


Tin tức khác


Báo chí viết về 1VS
25/12/2015
Giải đáp vướng mắc trong lập Báo cáo tài chính năm 2015:

"Nội dung chính của sự kiện là tập trung hướng dẫn rà soát từng tài khoản trước khi lập báo cáo tài chính, chỉ ra những điểm cần lưu ý, hay sai sót, và những rủi ro về thuế khi lập báo cáo tài chính năm 2015. Trong đó, có nêu rõ những khác biệt giữa các đơn vị thực hiện theo quyết định 48 và thông tư 200".

10/08/2015
Ứng dụng dịch vụ đám mây cho các giải pháp kế toán và quản lý 1C - Đài Truyền hình Kỹ thuật số VTC (VTC1):
Điện toán đám mây là xu thế tất yếu của nền công nghệ hiện đại. Với việc đưa lên mây nhiều giải pháp như kế toán, bán hàng, quản lý tổng thể doanh nghiệp... dịch vụ đám mây của 1C được nhiều doanh nghiệp ứng dụng để tự động hóa công tác quản lý trong nhiều lĩnh vực. 
01/06/2015
Phần mềm kế toán 1C: Một dữ liệu cho hàng trăm khách hàng - Báo Tài chính điện tử:
"... Thứ nhất, đám mây 1C của chúng tôi sử dụng cơ chế chia tách dữ liệu Multitenancy. Với cơ chế này, 1VS chỉ cần quản lý 1 dữ liệu phần mềm duy nhất dùng chung cho hàng trăm, hàng nghìn khách hàng của mình. Trong đó, có chia tách thành các vùng dữ liệu riêng của mỗi khách hàng, đảm bảo tính riêng tư của từng vùng dữ liệu. Nhờ công nghệ này, chúng tôi giảm được tới mức tối thiểu về thời gian, công sức và chi phí cho việc bảo trì sản phẩm trong đám mây.".